[Python-ideas] Dictionary destructing and unpacking.

[Nick Coghlan]

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