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.com