On Jul 23, 2017 1:56 PM, "MRAB" <pyt...@mrabarnett.plus.com> wrote:
On 2017-07-23 17:08, Todd wrote:
> On Jul 20, 2017 1:13 AM, "David Mertz" <me...@gnosis.cx <mailto:
> me...@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
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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
