<div dir="ltr">Just for sake of completeness  since people are talking about a namedtuple overhaul, I have a couple implementations here - <br><br><a href="https://github.com/jsbueno/extradict/blob/master/extradict/extratuple.py">https://github.com/jsbueno/extradict/blob/master/extradict/extratuple.py</a><br><br>If any idea there can help inspiring someone, I will be happy. <div><br></div><div>  js</div><div> -><-</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 July 2017 at 18:26, Barry Warsaw <span dir="ltr"><<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Jul 17, 2017, at 16:31, Giampaolo Rodola' <<a href="mailto:g.rodola@gmail.com">g.rodola@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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:<br>
><br>
> >>> ntuple(x=1, y=0)<br>
> (x=1, y=0)<br>
><br>
> ...or even a literal as in:<br>
><br>
> >>> (x=1, y=0)<br>
> (x=1, y=0)<br>
><br>
> 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").<br>
<br>
</div></div><br>______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>jsbueno%40python.org.br</a><br>
<br></blockquote></div><br></div>