Add ** Map Unpacking Support for namedtuple

[JohnCrawford]

BPO	32854
Nosy	@rhettinger, @serhiy-storchaka, @jcrotts

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2018-03-04.21:50:45.691>
created_at = <Date 2018-02-15.18:10:32.891>
labels = ['3.7', '3.8', 'type-feature', 'library']
title = 'Add ** Map Unpacking Support for namedtuple'
updated_at = <Date 2018-03-04.21:50:45.690>
user = 'https://bugs.python.org/JohnCrawford'

bugs.python.org fields:

activity = <Date 2018-03-04.21:50:45.690>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2018-03-04.21:50:45.691>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2018-02-15.18:10:32.891>
creator = 'John Crawford'
dependencies = []
files = []
hgrepos = []
issue_num = 32854
keywords = []
message_count = 7.0
messages = ['312218', '312219', '312220', '312252', '312276', '312277', '312359']
nosy_count = 4.0
nosy_names = ['rhettinger', 'serhiy.storchaka', 'jcrotts', 'John Crawford']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue32854'
versions = ['Python 3.7', 'Python 3.8']

[JohnCrawford]

At present, collections.namedtuple does not support ** map unpacking despite being a mapping style data structure. For example:

    >>> from collections import namedtuple
    >>> A = namedtuple("A", "a b c")
    >>> a = A(10, 20, 30)
    >>> def t(*args, **kwargs):
    ...     print(f'args={args!r}, kwargs={kwargs!r}')
    ...
    >>> t(*a)
    args=(10, 20, 30), kwargs={}
    >>> t(**a)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: t() argument after ** must be a mapping, not A
    >>> 

No doubt, the lack of current support is due to namespace conflicts that result from trying to provide a keys method amidst also supporting attribute-style access to the namedtuple class. As we can see, providing a keys attribute in the namedtuple produces an interesting result:

    >>> Record = namedtuple("Record", "title keys description")
    >>> t(**Record(1, 2, 3))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: attribute of type 'int' is not callable
    >>>

To me, this calls out a design flaw in the ** unpacking operator where it depends on a method that uses a non-system naming convention. It would make far more sense for the ** operator to utilize a __keys__ method rather than the current keys method. After all, the __<methodname>__ naming convention was introduced to avoid namespace conflict problems like this one.

[rhettinger]

The intended way to support **unpacking is the _asdict() method:

    t(**a._asdict())

It doesn't really make sense to add direct support for **unpacking because named tuples are sequences and not mappings. To support **unpacking, we would have to add a keys() method and modify __getitem__() to handle both integer indexing and string key lookup. Once we have **a and a[k] and a.keys(), people would also want a.values() a.items() etc. The world gets murky when both sequence and mapping behaviors become commingled.

[serhiy-storchaka]

Concur with Raymond.

[jcrotts]

Would it be worth adding an example of unpacking such as, t(**a._asdict()), or something similar to the documentation ?

[rhettinger]

Would it be worth adding an example of unpacking such as,
t(**a._asdict()), or something similar to the documentation ?

There are a myriad of uses for dictionaries and the namedtuple docs don't seem like to right place to cover them (**unpacking, str.format_map, str.__mod__, etc). Even the dict and OrderedDict docs don't cover these.

Also, the use of somefunc(**nt._asdict()) isn't a common pattern. A requirement for **unpacking tends to nudge design choices towards an actual mapping rather than a tuple or tuple subclass for the underlying data store. That is likely why this hasn't come-up before.

[serhiy-storchaka]

I wandering if it is worth to add a general function that takes an object and a sequence of keys and return a mapping proxy that maps attribute names to values.

[jcrotts]

Thanks Raymond, I wasn't sure if it was a common pattern or not, that makes sense.