homepage

I am attaching a proof-of-concept patch that changes the bytecode 
generated from {1:1,2:2,3:3,4:4} from 
BUILD_MAP 4 
LOAD_CONST 2 (1) 
LOAD_CONST 2 (1) 
STORE_MAP 
LOAD_CONST 1 (2) 
LOAD_CONST 1 (2) 
STORE_MAP 
LOAD_CONST 4 (3) 
LOAD_CONST 4 (3) 
STORE_MAP 
LOAD_CONST 3 (4) 
LOAD_CONST 3 (4) 
STORE_MAP 
to
LOAD_CONST 1 (4) 
LOAD_CONST 1 (4) 
LOAD_CONST 2 (3) 
LOAD_CONST 2 (3) 
LOAD_CONST 3 (2) 
LOAD_CONST 3 (2) 
LOAD_CONST 4 (1) 
LOAD_CONST 4 (1) 
BUILD_MAP 4 
 
and changes BUILD_MAP to behave similarly to BUILD_(SET|LIST|TUPLE) and 
consume 2*n items from the stack.
The advantage is more compact and faster bytecode and uniform treatment 
of BUILD_* instructions.

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 the best way to treat both set 
and dict literals. The truth may very well be that up to certain size 
it is better to build set/dict all at once from the stack, but past that 
size incremental insertion is better. The hybrid approach would be easy 
to implement.

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.

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 building dict literals, 
it would be unfortunate if that order were specified differently for 
dict and set literals.
I will think some more about the stack issue. There is a valid argument 
that large dict literals will be more common than large set literals, so 
the stack issue is more important for dicts.
BTW, what is the status of making set literal a frozen set proposal?

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 still needs to go forward though.

Python-3000 discussion <http://mail.python.org/pipermail/python-
3000/2008-March/012753.html> did not reveal any opposition to the idea 
of batch processing of dict displays. However, a compromise suggestion 
was made to limit batches to 256 items 
<http://mail.python.org/pipermail/python-3000/2008-March/012829.html>. 
I don't think this type of micro-optimization belongs to the core. A 
rare application that would benefit from limited size batch processing 
can do so explicitly using dict.update.
See also relevant discussion at issue2292 (starting at msg65111).
I believe this issue can be reopen. I will submit documentation patch 
if the change is accepted in principle.

-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 the cost of one time around the eval-
loop is tiny in comparison to the cost of inserting a new dict entry). 
Besides, dict literals almost never occur in the inner-loops of time 
critical code. 
I recommend that this stay closed. Better to aim for meaningful 
optimizations using the AST and avoid micro-optimizations that subtly 
change semantics.