I'm not sure why everybody have such a grip on the type. When we use regular tuples, noone care, it's all tuples, no matter what. Well in that case, let's make all those namedtuple and be done with it. If somebody really needs a type, this person will either used collections.namedtuple the old way, or use a namespace or a class. If using the type "namedtuple" is an issue because it already exist, let's find a name for this new type that convey the meaning, like labelledtuple or something. The whole point of this is to make it a litteral, simple and quick to use. If you make it more than it is, we already got everything to do this and don't need to modify the language. Le 23/07/2017 à 18:08, Todd a écrit :
On Jul 20, 2017 1:13 AM, "David Mertz" <mertz@gnosis.cx <mailto:mertz@gnosis.cx>> wrote:
I'm concerned in the proposal about losing access to type information (i.e. name) in this proposal. For example, I might write some code like this now:
>>> from collections import namedtuple >>> Car = namedtuple("Car", "cost hp weight") >>> Motorcycle = namedtuple("Motorcycle", "cost hp weight") >>> smart = Car(18_900, 89, 949) >>> harley = Motorcyle(18_900, 89, 949) >>> if smart==harley and type(smart)==type(harley): ... print("These are identical vehicles")
The proposal to define this as:
>>> smart = (cost=18_900, hp=89, weight=949) >>> harley = (cost=18_900, hp=89, weight=949)
Doesn't seem to leave any way to distinguish the objects of different types that happen to have the same fields. Comparing `smart._fields==harley._fields` doesn't help here, nor does any type constructed solely from the fields.
What about making a syntax to declare a type? The ones that come to mind are
name = (x=, y=)
Or
name = (x=pass, y=pass)
They may not be clear enough, though.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/