[Python-ideas] Dictionary destructing and unpacking.

[Nick Badger]

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 <ncoghlan at gmail.com>:

> On 8 June 2017 at 17:49, Paul Moore <p.f.moore at gmail.com> wrote:
> > On 8 June 2017 at 08:15, Stephen J. Turnbull
> > <turnbull.stephen.fw at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> 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/20170608/299bfb28/attachment.html>