Just for sake of completeness since people are talking about a namedtuple overhaul, I have a couple implementations here -
https://github.com/jsbueno/extradict/blob/master/extradict/extratuple.py If any idea there can help inspiring someone, I will be happy. js -><- On 17 July 2017 at 18:26, Barry Warsaw <ba...@python.org> wrote: > 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"). > > > _______________________________________________ > 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/ > jsbueno%40python.org.br > >
_______________________________________________ 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
