<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, May 25, 2016 at 7:41 PM Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   a, b = mapping<br>
   a, b, **_ = mapping  # when you don't care about the rest<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Also, I wonder if the implementation will be more difficult. In tuple unpacking, it's the LHS that provides the semantic meaning. The RHS is just duck-typed. What's the appropriate error message if you meant to do dict unpacking and didn't have a mapping on the RHS?</div><div><br></div><div><div>    py> a, b = 42</div><div><span style="line-height:1.5">    TypeError: 'int' object is not iterable</span><br></div></div><div><span style="line-height:1.5">    py> </span>{'a': x, 'b': y} = 42</div><div>    TypeError: 'int' object is not subscriptable</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that most Pythonistas would say:<br>
   a, b = 1, 2  # look ma!  no round brackets!<br></blockquote><div><br></div><div>You need brackets for nested/recursive destructuring.</div><div><br></div><div>    py> a, b, (c, d) = 1, 2, (3, 4)</div><div>    py> {'a': x, 'b': {'c': y, 'd': z} = {'a': 1, 'b': {'c': 2, 'd': 3}}</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">matching syntax is out-of-scope for an<br>
unpacking proposal.  At most, it should be a "let's not paint ourselves<br>
into a corner" type of concern -- and I must admit I don't see why<br>
   a, b, c = some_dict<br>
rules out<br>
  {'x': a, 'y':b} = some_dict<br>
as a pattern-matching construct.<br></blockquote><div><br></div><div>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.</div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">    py> a, b, c, 0 = 1, 2, 3, 4</span></div><div><span style="line-height:1.5">    ValueError: index 3 does not match value 0</span></div><div><span style="line-height:1.5">    py> {'x': a, 'y': 0} = {'x': 1, 'y': 2}</span></div><div><span style="line-height:1.5">    ValueError: key 'y' does not match value 0</span></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> On Wed, May 25, 2016 at 11:18 AM Paul Moore wrote:<br>>> get a set of elements and *ignore* the rest:<br><br>
Since you've repeated yourself, I will too.  ;)<br></blockquote><div><br></div><div>I figured repetition was more clear than "see above". :-)</div></div></div>