On Thu, Jul 20, 2017 at 9:58 AM, Nathaniel Smith <njs@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 +