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? [1]

...

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.

-- ~Ethan~

[1] 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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

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? [1]

...

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.

-- ~Ethan~

[1] 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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/