Message234493
| Author | Joshua.Landau |
|---|---|
| Recipients | Jeff.Kaufman, Joshua.Landau, NeilGirdhar, Rosuav, SpaghettiToastBook, andybuckley, belopolsky, berker.peksag, eric.araujo, eric.snow, ezio.melotti, georg.brandl, gvanrossum, ncoghlan, paul.moore, pconnell, r.david.murray, terry.reedy, twouters, zbysz |
| Date | 2015-01-22.14:32:43 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1421937164.05.0.398990033932.issue2292@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I've looked at BUILD_MAP(n). It seems to work and has speed improvements but:
- I was wrong about the 16-bit int thing. It turns out CPython is happily treating them as 32 bit as long as they are prefixed by an EXTENDED_ARG bytecode
https://docs.python.org/3/library/dis.html#opcode-EXTENDED_ARG
This could be used by BUILD_MAP rather than falling back to BUILD_MAP_UNPACK.
- It's probably best to not include it here, since it's a disjoint issue. This patch wouldn't really be affected by its absence.
Also, if we limit BUILD_MAP_MERGE to 255 dictionaries, this will also apply to the {**a, **b, **c, ...} syntax, although I really can't see it being a problem. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2015-01-22 14:32:44 | Joshua.Landau | set | recipients: + Joshua.Landau, gvanrossum, twouters, georg.brandl, terry.reedy, paul.moore, ncoghlan, belopolsky, ezio.melotti, eric.araujo, andybuckley, r.david.murray, zbysz, eric.snow, Rosuav, berker.peksag, pconnell, NeilGirdhar, Jeff.Kaufman, SpaghettiToastBook |
| 2015-01-22 14:32:44 | Joshua.Landau | set | messageid: <1421937164.05.0.398990033932.issue2292@psf.upfronthosting.co.za> |
| 2015-01-22 14:32:44 | Joshua.Landau | link | issue2292 messages |
| 2015-01-22 14:32:43 | Joshua.Landau | create | |