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

[Paul Moore]

On 20 July 2017 at 07:58, Nathaniel Smith <njs at pobox.com> wrote:
> 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.

Agreed. This discussion was prompted by the fact that namedtuple class
creation was slow, resulting in startup time issues. It seems to have
morphed into a generalised discussion of how we design a new "named
values" type. While I know that if we're rewriting the implementation,
that's a good time to review the semantics, but it feels like we've
gone too far in that direction.

As has been noted, the new proposal

- no longer supports multiple named types with the same set of field names
- doesn't allow creation from a simple sequence of values

I would actually struggle to see how this can be considered a
replacement for namedtuple - it feels like a completely independent
beast. Certainly code intended to work on multiple Python versions
would seem to have no motivation to change.

> 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?

Agreed. Now that keyword argument dictionaries retain their order,
there's no need for new syntax here. In fact, that's one of the key
motivating reasons for the feature.

Paul