[Python-ideas] Yet More Unpacking Generalizations (or, Dictionary Literals as lvalues)

[Scott Sanderson]

>
> This sounds reasonable in theory; is it going to have problems with
> the non-orderedness of dictionaries?


You can make this deterministic by always iterating over the LHS keys in 
declaration order.  Expressed another way, dictionary **literals** can be 
ordered, even if dictionaries themselves are not ordered at runtime.  We 
only need to have a well-defined order when generating opcodes at compile 
time.  I think you were getting at this same idea with your proposal as 
well.

Unless, of course, this doesn't "pop" and "push", but does some sort
> of replacement. Suppose you load the keys first, and only once those
> are loaded, you load the rvalue - so the rvalue is on the top of the
> stack. "UNPACK_MAP 3" means this:


I think you could make this work with either stack ordering; the compiler 
would be generating both the UNPACK_* calls and the LOAD_* calls all at 
once, so it could decide to order them however the interpreter found it 
most convenient to work with.  I think there are already opcodes that 
operate on the top N elements of the stack, so whether we're actually doing 
true pushes and pops is just an implementation detail.

I do agree that the accesses should happen in the order that the keys 
appear in the LHS, and I'd expect nested structures to be traversed 
depth-first, which would matter if the same leaf name appeared in multiple 
places.  This would be analogous to the fact that

a, a = (1, 2)

results in the value of a being 2.

-Scott

On Wednesday, August 12, 2015 at 12:10:43 PM UTC-4, Chris Angelico wrote:
>
> On Wed, Aug 12, 2015 at 11:57 PM, Scott Sanderson 
> <scott.b.s... at gmail.com <javascript:>> wrote: 
> > LOAD_NAME 'values'  # Push rvalue onto the stack. 
> > LOAD_CONST 'dict'   # Push top-level keys onto the stack. 
> > LOAD_CONST 'tuple' 
> > LOAD_CONST 'name' 
> > UNPACK_MAP 3        # Unpack keys. Pops values and all keys from the 
> stack. 
> >                     # TOS  = values['name'] 
> >                     # TOS1 = values['tuple'] 
> >                     # TOS2 = values['dict'] 
> > 
> > STORE_FAST name     # Terminal names are simply stored. 
> > 
> > UNPACK_SEQUENCE 2   # Push the two entries in values['tuple'] onto the 
> > stack. 
> >                     # TOS  = values['tuple'][0] 
> >                     # TOS1 = values['tuple'][1] 
> >                     # TOS2 = values['dict'] 
> > STORE_FAST x 
> > STORE_FAST y 
>
> This sounds reasonable in theory; is it going to have problems with 
> the non-orderedness of dictionaries? With sequence unpacking, it's 
> straight-forward - you evaluate things in a known order, you iterate 
> over the thing, you assign. In this case, you might end up with some 
> bizarre stack manipulation needed to make this work. Inside that 
> UNPACK_MAP opcode, arbitrary code could be executed (imagine if the 
> RHS is not a dict per se, but an object with a __getitem__ method), so 
> it'll need to be popping some things off and pushing others on, and 
> presumably would need to know what goes where. 
>
> Unless, of course, this doesn't "pop" and "push", but does some sort 
> of replacement. Suppose you load the keys first, and only once those 
> are loaded, you load the rvalue - so the rvalue is on the top of the 
> stack. "UNPACK_MAP 3" means this: 
>
> 1) Pop the top item off the stack - it is the map we're working with. 
> 2) Reach 3 items down in the stack. Take that item, subscript our map 
> with it, and replace that stack entry with the result. 
> 3) Reach 2 items down, subscript, replace. Repeat till we subscript 
> with the top of the stack. 
>
> I've no idea how plausible that is, but it'd kinda work. It would also 
> mean you could evaluate the keys in the order that they're shown in 
> the dict display *and* assign to them in that order, which the current 
> proposal doesn't do (it assigns in order, but evaluates in reverse 
> order). 
>
> Stupid, unworkable idea? 
>
> ChrisA 
> _______________________________________________ 
> Python-ideas mailing list 
> Python... at python.org <javascript:> 
> https://mail.python.org/mailman/listinfo/python-ideas 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150812/6d302f63/attachment.html>