On Wed, May 25, 2016 at 7:41 PM Ethan Furman <ethan@stoneleaf.us> 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. 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? py> a, b = 42 TypeError: 'int' object is not iterable py> {'a': x, 'b': y} = 42 TypeError: 'int' object is not subscriptable 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) py> {'a': x, 'b': {'c': y, 'd': z} = {'a': 1, 'b': {'c': 2, 'd': 3}} matching syntax is out-of-scope for an
unpacking proposal. At most, it should be a "let's not paint ourselves into a corner" type of concern -- and I must admit I don't see why a, b, c = some_dict rules out {'x': a, 'y':b} = some_dict as a pattern-matching construct.
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
On Wed, May 25, 2016 at 11:18 AM Paul Moore wrote:
get a set of elements and *ignore* the rest:
Since you've repeated yourself, I will too. ;)
I figured repetition was more clear than "see above". :-)