Well, it's not deliberately not destructive, but I'd be more in favor of dict unpacking-assignment if it were spelled more like this:
>>> foo = {'a': 1, 'b': 2, 'c': 3, 'd': 4} >>> {'a': bar, 'b': baz, **rest} = foo >>> bar 1 >>> baz 2 >>> rest {'c': 3, 'd': 4} >>> foo {'a': 1, 'b': 2, 'c': 3, 'd': 4} That also takes care of the ordering issue, and any ambiguity about "am I unpacking the keys, the values, or both?", at the cost of a bit more typing. However, I'm a bit on the fence about this syntax as well: it's pretty easily confused with dictionary creation. Maybe the same thing but without the brackets? Just a thought I had this morning. Nick Nick Badger https://www.nickbadger.com 2017-06-08 7:00 GMT-07:00 Nick Coghlan <ncogh...@gmail.com>: > On 8 June 2017 at 17:49, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 8 June 2017 at 08:15, Stephen J. Turnbull > > <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > >> If you like this feature, and wish it were in Python, I genuinely wish > >> you good luck getting it in. My point is just that in precisely that > >> use case I wouldn't be passing dictionaries that need destructuring > >> around. I believe that to be the case for most Pythonistas. > >> (Although several have posted in favor of some way to destructure > >> dictionaries, typically those in favor of the status quo don't speak > >> up until it looks like there will be a change.) > > > > The most common use case I find for this is when dealing with JSON (as > > someone else pointed out). But that's a definite case of dealing with > > data in a format that's "unnatural" for Python (by definition, JSON is > > "natural" for JavaScript). While having better support for working > > with JSON would be nice, I typically find myself wishing for better > > JSON handling libraries (ones that deal better with mappings with > > known keys) than for language features. But of course, I could write > > such a library myself, if it mattered sufficiently to me - and it > > never seems *that* important :-) > > Aye, I've had good experiences with using JSL to define JSON schemas > for ad hoc JSON data structures that didn't already have them: > https://jsl.readthedocs.io/en/latest/ > > And then, if you really wanted to, something like JSON Schema Objects > provides automated destructuring and validation based on those > schemas: https://python-jsonschema-objects.readthedocs.io/en/ > latest/Introduction.html > > However, it really isn't an ad hoc scripting friendly way to go - it's > an "I'm writing a tested-and-formally-released application and want to > strictly manage the data processing boundaries between components" > style solution. > > pandas.read_json is pretty nice > (https://pandas.pydata.org/pandas-docs/stable/generated/ > pandas.read_json.html), > but would be a heavy dependency to bring in *just* for JSON -> > DataFrame conversions. > > For myself, the things I mainly miss are: > > * getitem/setitem/delitem counterparts to getattr/setattr/delattr > * getattrs and getitems builtins for retrieving multiple attributes or > items in a single call (with the default value for missing results > moved to a keyword-only argument) > > Now, these aren't hard to write yourself (and you can even use > operator.attrgetter and operator.itemgetter as part of building them), > but it's a sufficiently irritating niggle not to have them at my > fingertips whenever they'd be convenient that I'll often end up > writing out the long form equivalents instead. > > Are these necessary? Clearly not (although we did decide > operator.itemgetter and operator.attrgetter were important enough to > add for use with the map() and filter() builtins and other itertools). > > Is it a source of irritation that they're not there? Absolutely, at > least for me. > > Cheers, > Nick. > > P.S. Just clearly not irritating enough for me to actually put a patch > together and push for a final decision one way or the other regarding > adding them ;) > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/