[Python-ideas] Dictionary destructing and unpacking.

[Neil Girdhar]

By the way, this is already in the CPython source code if I remember from 
when I worked on 448.  The code for dict unpacking is merely blocked.  I 
like this syntax from a purity standpoint, but I don't think I would use it 
that much. 

On Thursday, June 8, 2017 at 3:18:21 PM UTC-4, Nick Badger wrote:
>
> 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 <ncog... at gmail.com <javascript:>>:
>
>> On 8 June 2017 at 17:49, Paul Moore <p.f.... at gmail.com <javascript:>> 
>> wrote:
>> > On 8 June 2017 at 08:15, Stephen J. Turnbull
>> > <turnbull.... at u.tsukuba.ac.jp <javascript:>> 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   |   ncog... at gmail.com <javascript:>   |   Brisbane, 
>> Australia
>> _______________________________________________
>> 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/20170627/a5b154de/attachment-0001.html>