[Python-ideas] Unpacking a dict

[Ethan Furman]

[Including replies to

On 05/25/2016 05:29 PM, Michael Selik wrote:
> On Wed, May 25, 2016 at 7:41 PM Ethan Furman wrote:

>>     a, b = mapping
>>     a, b, **_ = mapping  # when you don't care about the rest
>
> I'd grudgingly accept this as a second-best syntax. It doesn't support
> keys that aren't strs of valid identifiers, but I suppose ``def
> foo(**kwargs)`` doesn't either. I frequently have keys that are strs
> with punctuation, keys that are tuples of ints, etc. Being restricted to
> identifiers feels cramped.

Doesn't have to be the only syntax, just the easiest.

[from other email]
------------------
 > Breaks backwards compatibility.
 >
 >      py> a, b = {'a': 1, 'b': 2}
 >      py> a, b
 >      ('b', 'a')

Ah.  That is a very good point.

I'll meet you halfway:

   {a, b} = some_dict

which is currently a SyntaxError, so little backwards compatibility 
concerns, plus it clearly state the mapping should have two elements, 
similarly to

  [a] = some_iterable

and

  (b) = some_iterable

both clearly state that a one-element iterable is being unpacked.

>> I think that most Pythonistas would say:
>>     a, b = 1, 2  # look ma!  no round brackets!
>
> You need brackets for nested/recursive destructuring.
>
>      py> a, b, (c, d) = 1, 2, (3, 4)

Sure, but that isn't the simple case.

>      py> {'a': x, 'b': {'c': y, 'd': z} = {'a': 1, 'b': {'c': 2, 'd': 3}}

With the above syntax:

   {a, b {c, d}} = a_mapping

> Yep. I just want to look ahead a bit. While you're considering dict
> unpacking syntax options, keep in mind that tuple matching will need to
> parallel dict matching. Also, our future selves will want
> one-way-to-do-it when considering matching syntaxes.
>
>      py> a, b, c, 0 = 1, 2, 3, 4
>      ValueError: index 3 does not match value 0
>      py> {'x': a, 'y': 0} = {'x': 1, 'y': 2}
>      ValueError: key 'y' does not match value 0

The adage is actually one /obvious/ way to do it -- which can change 
depending on the circumstances.

On 05/25/2016 07:16 PM, David Mertz wrote:
 > I can see how this spelling might be intuitive at first brush.  But
 > the more I think about it, the more I recoil against the violation of
 > a relatively uniform semantic principle in Python.
 >
 > In no other case in Python, does the RHS of an assignment "probe
 > into" the LHS to figure out how to determine its value.  Moreover,
 > the idea that variable names are not just bindings, but also pseudo-
 > literals, or maybe something akin to a Lisp 'symbol', feels enormously
 > unpythonic to me.

On 05/25/2016 07:18 PM, Guido van Rossum wrote:
 > I have to warn here. This looks cool but it does something that AFAIK
 > no other Python syntax uses -- it takes variable names and does
 > something to those variables but *also* uses their actual names as
 > string literals. I agree that the use cases for this seem pretty
 > sweet, but perhaps we should give it a somewhat different syntax just
 > so it's clear that the names on the LHS matter. The precedent that the
 > targets must be actual names rather than anything you can assign to is
 > also kind of scary.

Very good points.  I'm glad we had the discussion, though, since it 
elicited Random's contribution -- which is what I will use from now on 
for dict unpacking.  :)

--
~Ethan~