Re: [Python-ideas] namedtuple redesign goals
Michel Desmoulin writes: > 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. Unlikely to fly in Python. We really don't like things that have "obvious semantics" based on appearance that don't have those semantics. Something like "(x=0, y=1)" is so obviously a literal creating a collections.namedtuple, the object it creates really needs to *be* a collections.namedtuple. YMMV, but I suspect most Python developers will agree with me to some extent, and most of those, pretty strongly. Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] namedtuple redesign goals
On 07/24/2017 09:49 AM, Michel Desmoulin wrote: 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. Ah, that makes sense. Personally, though, I'm not excited about another namedtuple variant. -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] namedtuple redesign goals
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/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] namedtuple redesign goals
[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. -- ~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/
[Python-ideas] namedtuple redesign goals
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:
--> from collections import namedtuple
--> Point = namedtuple('Point', 'x y')
--> p1 = Point(3, 7)
--> p1.x
3
--> p1.y
7
--> isinstance(p1, Point)
True
--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
