[Python-Dev] Impact of Namedtuple on startup time (original) (raw)

Barry Warsaw barry at python.org
Mon Jul 17 17:26:24 EDT 2017

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.rodola at 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").

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: <http://mail.python.org/pipermail/python-dev/attachments/20170717/9ae06933/attachment.sig>

More information about the Python-Dev mailing list