[Python-ideas] namedtuple literals [Was: RE a new namedtuple]
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:
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
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 Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas