[issue2197] Further simplify dict literal bytecode

New submission from Alexander Belopolsky: I am attaching a proof-of-concept patch that changes the bytecode generated from {1:1,2:2,3:3,4:4} from BUILD_MAP4 LOAD_CONST 2 (1) LOAD_CONST 2 (1) STORE_MAP LOAD_CONST 1 (2)

[issue2197] Further simplify dict literal bytecode

Alexander Belopolsky added the comment: Hmm, it looks like this was considered before (issue402227), but back then there were no set literals. If stack-saving approach is better for dicts, it should be better for sets as well. In any case, maybe it is time to revisit the issue and decide on

[issue2197] Further simplify dict literal bytecode

Raymond Hettinger added the comment: This changes semantics by executing all of the stores after the inputs are generated. All of the pending item pairs get built-up on an ever- growing stack instead of being consumed pairwise, never deepening the stack by more than two. -- nosy: +rhe

[issue2197] Further simplify dict literal bytecode

Alexander Belopolsky added the comment: I did not think of the insertion after creation change of semantics. Do I understand that this is important when keys have custom comparison/hash methods with side-effects. If it is important for the language to guarantee the create/insert order in bui

[issue2197] Further simplify dict literal bytecode

Sean Reifschneider <[EMAIL PROTECTED]> added the comment: As addition thought is required by Alexander, I'm going to close this as postponed and you can re-open it if after further consideration you think it needs to be applied. Probably would be good to discuss on python-dev if you think it sti

[issue2197] Further simplify dict literal bytecode

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: Python-3000 discussion did not reveal any opposition to the idea of batch processing of dict displays. However, a compromise suggestion was made to limit batches

[issue2197] Further simplify dict literal bytecode

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: -1 I don't think this is worth the semantic change. The current approach doesn't require special cases for different dict sizes. The code/time savings is very small (seven bytes of opcodes per item get condensed by only one byte and t