[Python-ideas] namedtuple redesign goals
desmoulinmichel at gmail.com
Mon Jul 24 12:49:04 EDT 2017
Le 24/07/2017 à 13:45, Ethan Furman a écrit :
> [redirecting back to list]
> On 07/24/2017 04:19 AM, Michel Desmoulin wrote:
>> Le 24/07/2017 à 13:02, Ethan Furman a écrit :
>>> On 07/23/2017 10:47 AM, Michel Desmoulin wrote:
>>>> I'm not sure why everybody have such a grip on the type.
>>> If I understand the goal of "a new namedtuple" correctly, it is not to
>>> come up with yet another namedtuple type -- it is to make the existing
>>> collections.namedtuple a faster experience, and possibly add another way
>>> to create such a thing.
>>> This means that the "replacement" namedtuple MUST be backwards
>>> compatible with the existing collections.namedtuple, and keeping track
>>> of type is one of the things it does:
>> Is it ? Maybe we should check that, cause we may be arguing around a
>> "nice to have" for nothing.
> Um, yes, it is. Did you not read the section you snipped? 
>> How many people among those intereted by the proposal have a strong
>> need for the type ?
> Whether there is a strong need for it is largely irrelevant; it's there
> now, it needs to stay. If we were to remove it there would need to be a
> strong need for what we gain and that it outweighs the broken backward
> compatibility commitment that we try very hard to maintain.
You are assuming a namedtuple litteral would mean collections.namedtuple
would lose the type hability. It's not the case. The litterals can be
complement, not a remplacement.
Accelerating namedtuple can be made by rewritting it in C. The litteral
namedtuple is not necessary for that.
>  My apologies for the first paragraph if this is a language
> translation issue and you were talking about the backwards compatibility
> and not the type tracking.
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
More information about the Python-ideas