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.
Guido has already declared that he doesn't like those bare forms, so it'll
On Jul 23, 2017 1:56 PM, "MRAB" <python@mrabarnett.plus.com> wrote: On 2017-07-23 17:08, Todd wrote: probably be something like ntuple(...). Not exactly a literal in that case. If this is true, why not simply add keyword arguments to tuple(...)? Something like (a=1, b=2, c=3) makes very clear sense to me, or even (1, 2, c=3), where the first two are accessible by index only. Or even (1, 2, c: 3), which reminds me of Elixir's expansion of tuple and list keywords. A tuple is a tuple is a tuple. No types. Just convenient accessors. -- C Anthony