Ben, I have a small package which enables one to do: with MapGetter(my_dictionary): from my_dictionary import a, b, parameter3 If this interests you, contributions so it can get hardenned for mainstram acceptance are welcome. https://github.com/jsbueno/extradict On 11 November 2017 at 04:26, Ben Usman wrote:

Got it, thank you. I'll go and check it out!

On Nov 11, 2017 01:22, "Jelle Zijlstra" wrote:

...

2017-11-10 19:53 GMT-08:00 Ben Usman :

...

The following works now:

seq = [1, 2] d = {'c': 3, 'a': 1, 'b': 2}

(el1, el2) = *seq el1, el2 = *seq head, *tail = *seq

seq_new = (*seq, *tail) dict_new = {**d, **{'c': 4}}

def f(arg1, arg2, a, b, c): pass

f(*seq, **d)

It seems like dict unpacking syntax would not be fully coherent with list unpacking syntax without something like:

{b, a, **other} = **d

Because iterables have both syntax for function call unpacking and "rhs in assignment unpacking" and dict has only function call unpacking syntax.

I was not able to find any PEPs that suggest this (search keywords: "PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0), however, let me know if I am wrong.

It was discussed at great length on Python-ideas about a year ago. There is a thread called "Unpacking a dict" from May 2016.

...

The main use-case, in my understating, is getting shortcuts to elements of a dictionary if they are going to be used more then ones later in the scope. A made-up example is using a config to initiate a bunch of things with many config arguments with long names that have overlap in keywords used in initialization.

One should either write long calls like

start_a(config['parameter1'], config['parameter2'], config['parameter3'], config['parameter4'])

start_b(config['parameter3'], config['parameter2'], config['parameter3'], config['parameter4'])

many times or use a list-comprehension solution mentioned above.

It becomes even worse (in terms of readability) with nested structures.

start_b(config['group2']['parameter3'], config['parameter2'], config['parameter3'], config['group2']['parameter3'])

## Rationale

Right now this problem is often solved using [list] comprehensions, but this is somewhat verbose:

a, b = (d[k] for k in ['a', 'b'])

or direct per-instance assignment (looks simple for with single-character keys, but often becomes very verbose with real-world long key names)

a = d['a'] b = d['b']

Alternatively one could have a very basic method\function get_n() or __getitem__() accepting more then a single argument

a, b = d.get_n('a', 'b') a, b = get_n(d, 'a', 'b') a, b = d['a', 'b']

All these approaches require verbose double-mentioning of same key. It becomes even worse if you have nested structures of dictionaries.

## Concerns and questions:

0. This is the most troubling part, imho, other questions are more like common thoughts. It seems (to put it mildly) weird that execution flow depends on names of local variables.

For example, one can not easily refactor these variable names. However, same is true for dictionary keys anyway: you can not suddenly decide and refactor your code to expect dictionaries with keys 'c' and 'd' whereas your entire system still expects you to use dictionaries with keys 'a' and 'b'. A counter-objection is that this specific scenario is usually handled with record\struct-like classes with fixed members rather then dicts, so this is not an issue.

Quite a few languages (closure and javascript to name a few) seem to have this feature now and it seems like they did not suffer too much from refactoring hell. This does not mean that their approach is good, just that it is "manageable".

1. This line seems coherent with sequence syntax, but redundant: {b, a, **other} = **d

and the following use of "throwaway" variable just looks poor visually {b, a, **_} = **d

could it be less verbose like this {b, a} = **d

but it is not very coherent with lists behavior.

E.g. what if that line did not raise something like "ValueError: Too many keys to unpack, got an unexpected keyword argument 'c'".

2. Unpacking in other contexts

{self.a, b, **other} = **d

should it be interpreted as self.a, b = d['a'], d['b']

or

self.a, b = d['self.a'], d['b']

probably the first, but what I am saying is that these name-extracting rules should be strictly specified and it might not be trivial.

--- Ben

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/jelle.zijlstra%40gmail.co...

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br

Do you mean making getitems call itemgetter? At the moment we can already do with itemgetter: from operator import itemgetter a,b = itemgetter("a", "b")(d)

I tend to post this every time the topic comes up, but: it's highly unlikely we'll get syntax for this when we don't even have a builtin to extract multiple items from a mapping in a single operation.

You mean subitems as attrgetter does? That would be actually quite cool! d = dict(a=dict(b=1), b=dict(c=2)) ab, ac = itemgetter("a.b", "b.c", separator=".")(d) I've created an issue in case something like that is desired: https://bugs.python.org/issue32010 No real strong push for it, happy to just close it if it does not get interest. That said I am not sure it solves Ben requests as he seamed to be targetting a way to bind the variable name with the dictionary keys implicitly. On 12 November 2017 at 10:06, Nick Coghlan wrote:

On 11 November 2017 at 16:22, Jelle Zijlstra wrote:

...

2017-11-10 19:53 GMT-08:00 Ben Usman :

...

I was not able to find any PEPs that suggest this (search keywords: "PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0), however, let me know if I am wrong.

It was discussed at great length on Python-ideas about a year ago. There is a thread called "Unpacking a dict" from May 2016.

I tend to post this every time the topic comes up, but: it's highly unlikely we'll get syntax for this when we don't even have a builtin to extract multiple items from a mapping in a single operation.

So if folks would like dict unpacking syntax, then a suitable place to start would be a proposal for a "getitems" builtin that allowed operations like:

b, a = getitems(d, ("b", "a"))

operator.itemgetter and operator.attrgetter may provide some inspiration for possible proposals.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ mariocj89%40gmail.com

Sounds like that happens quite often. Yep, I totally agree with your point, I think I mentioned something like this in the post as a possible partial solution: a drop-in replacement for an ugly list compression people seem to be using now to solve the problem. It's easy to implement, but the adoption by community is questionable. I mean, if this is a relatively rare use case, but those who need it seem to have their own one-liners for that already, is there even a need for a method or function like this in standard library? To unify to improve readability (single standard "getitems" instead of many different get_n, gets, get_mutliple)? The only motivation I can think of, and even it is questionable. On Nov 12, 2017 05:06, "Nick Coghlan" wrote: On 11 November 2017 at 16:22, Jelle Zijlstra wrote:

2017-11-10 19:53 GMT-08:00 Ben Usman :

...

I was not able to find any PEPs that suggest this (search keywords: "PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0), however, let me know if I am wrong.

It was discussed at great length on Python-ideas about a year ago. There is a thread called "Unpacking a dict" from May 2016.

I tend to post this every time the topic comes up, but: it's highly unlikely we'll get syntax for this when we don't even have a builtin to extract multiple items from a mapping in a single operation. So if folks would like dict unpacking syntax, then a suitable place to start would be a proposal for a "getitems" builtin that allowed operations like: b, a = getitems(d, ("b", "a")) operator.itemgetter and operator.attrgetter may provide some inspiration for possible proposals. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia