[Python-ideas] namedtuple literals [Was: RE a new namedtuple]

Koos Zevenhoven k7hoven at gmail.com
Thu Jul 20 08:35:41 EDT 2017

On Thu, Jul 20, 2017 at 9:58 AM, Nathaniel Smith <njs at pobox.com> wrote:

> The problem with namedtuple's semantics are that they're perfect for
> its original use case (replacing legacy tuple returns without breaking
> backwards compatibility), but turn out to be sub-optimal for pretty
> much anything else, which is one of the motivations behind stuff like
> attrs and Eric's dataclasses PEP:
>     https://github.com/ericvsmith/dataclasses/blob/
> 61bc9354621694a93b215e79a7187ddd82000256/pep-xxxx.rst#why-not-namedtuple
​Well put! I agree that adding attribute names to elements in a tuple (e.g.
return values) in a backwards-compatible way is where namedtuple is great.

>From the above it sounds like this ntuple literal idea would be giving
> us a third independent way to solve this niche use case (ntuple,
> namedtuple, structseq). This seems like two too many? Especially given
> that namedtuple is already arguably *too* convenient, in the sense
> that it's become an attractive nuisance that gets used in places where
> it isn't really appropriate.
​I do think it makes sense to add a convenient way to upgrade a function to
return named values. Is there any reason why that couldn't replace
structseq completely?

These anonymous namedtuple classes could also be made fast to create (and
more importantly, cached).

> Also, what's the advantage of (x=1, y=2) over ntuple(x=1, y=2)? I.e.,
> why does this need to be syntax instead of a library?
Indeed, we might need the syntax (x=1, y=2) later for something different.
However, I hope we can forget about 'ntuple', because it suggests a tuple
of n elements.

Maybe something like

    return tuple.named(x=foo, y=bar)

which is backwards compatible with

    return foo, bar

​-- Koos

+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170720/e0440bec/attachment.html>

More information about the Python-ideas mailing list