On 20 July 2017 at 10:15, Clément Pit-Claudel <cpitclaudel@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.