namedtuple is great and clever, but it’s also a bit clunky.  It has a weird 
signature and requires a made up type name.  It’s also rather unPythonic if you 
want to support default arguments when creating namedtuple instances.  Maybe as 
you say, a lot of the typical use cases for namedtuples could be addressed by a 
better builtin, but I fear we’ll end up down the bikeshedding hole for that.

-Barry

> On Jul 17, 2017, at 16:31, Giampaolo Rodola' <g.rod...@gmail.com> wrote:
> 
> I completely agree. I love namedtuples but I've never been too happy about 
> the additional overhead vs. plain tuples (both for creation and attribute 
> access times), to the point that I explicitly avoid to use them in certain 
> circumstances (e.g. a busy loop) and only for public end-user APIs returning 
> multiple values.
> 
> To be entirely honest, I'm not even sure why they need to be forcefully 
> declared upfront in the first place, instead of just having a first-class 
> function (builtin?) written in C:
> 
> >>> ntuple(x=1, y=0)
> (x=1, y=0)
> 
> ...or even a literal as in:
> 
> >>> (x=1, y=0)
> (x=1, y=0)
> 
> Most of the times this is what I really want: quickly returning an anonymous 
> tuple with named attributes and nothing else, similarly to os.times() & 
> others. I believe that if something like this would exist we would witness a 
> big transition from tuple() to ntuple() for all those functions returning 
> more than 1 value. We witnessed a similar transition in many parts of the 
> stdlib when collections.namedtuple was first introduced, but not everywhere, 
> probably because declaring a namedtuple is more work, it's more expensive, 
> and it still feels like you're dealing with some kind of too high-level 
> second-class citizen with too much overhead and too many sugar in terms of 
> API (e.g. "verbose", "rename", "module" and "_source").

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to