[Python-ideas] namedtuple literals [Was: RE a new namedtuple]

[Paul Moore]

On 20 July 2017 at 10:15, Clément Pit-Claudel <cpitclaudel at gmail.com> wrote:
> On 2017-07-20 11:02, Paul Moore wrote:
>>> 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?
>>
>> Agreed. Now that keyword argument dictionaries retain their order,
>> there's no need for new syntax here. In fact, that's one of the key
>> motivating reasons for the feature.
>
> Isn't there a speed aspect?  That is, doesn't the library approach require creating (and likely discarding) a dictionary every time a new ntuple is created?  The syntax approach wouldn't need to do that.

I don't think anyone has suggested that the instance creation time
penalty for namedtuple is the issue (it's the initial creation of the
class that affects interpreter startup time), so it's not clear that
we need to optimise that (at this stage). However, it's also true that
namedtuple instances are created from sequences, not dictionaries
(because the class holds the position/name mapping, so instance
creation doesn't need it). So it could be argued that the
backward-incompatible means of creating instances is *also* a problem
because it's slower...

Paul

PS Taking ntuple as "here's a neat idea for a new class", rather than
as a possible namedtuple replacement, changes the context of all of
the above significantly. Just treating ntuple purely as a new class
being proposed, I quite like it, but I'm not sure it's justified given
all of the similar approaches available, so let's see how a 3rd party
implementation fares. And it's too early to justify new syntax, but if
the overhead of a creation function turns out to be too high in
practice, we can revisit that question. But that's *not* what this
thread is about, as I understand it.