On Thu, Jul 20, 2017 at 9:58 AM, Nathaniel Smith <n...@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 +
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
