(original) (raw)

On Nov 12, 2017 02:12, "Joao S. O. Bueno" <jsbueno@python.org.br> wrote:

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

Your VersionDict in fact has some similarities to what I have thought of implementing using the PEP 555 machinery, but it is also a bit different. Interesting...

-- Koos (mobile)

On 11 November 2017 at 04:26, Ben Usman <bigobangux@gmail.com> wrote:
\> Got it, thank you. I'll go and check it out!
\>
\> On Nov 11, 2017 01:22, "Jelle Zijlstra" <jelle.zijlstra@gmail.com> wrote:
\>>
\>>
\>>
\>> 2017-11-10 19:53 GMT-08:00 Ben Usman <bigobangux@gmail.com>:
\>>>
\>>> 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
\>>>
\>>
\>
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> 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

>
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
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/k7hoven%40gmail.com