(original) (raw)

My final vote goes to "distinct type alias".
But how should we call the function? NewType? Or should we change it to DistinctAlias or something?

--
Ivan

28 Тра 2016 19:14 "Guido van Rossum" <guido@python.org> пише:

Ohhhhh, another D-word! I really like distinct.

On Sat, May 28, 2016 at 8:19 AM, Steve Dower <steve.dower@python.org> wrote:
\> Did anyone suggest "distinct type alias"?
\>
\> Regardless of what name, I'm fairly sure people will call it whatever the
\> function to create it is called. So if the function is
\> typings.distinguish\_type(...), then distinguished will stick.
\>
\> Top-posted from my Windows Phone
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> From: Guido van Rossum
\> Sent: ‎5/‎28/‎2016 7:38
\> To: Steven D'Aprano
\> Cc: Python-Dev
\> Subject: Re: \[Python-Dev\] Adding NewType() to PEP 484
\>
\> Just to add to the list of options, Twitter also came up with
\>
\> - invention
\>
\> - DomainType
\>
\> - TypedAlias
\>
\> But seriously I think we should just decide between Derived Type and
\> Distinguished Type \[Alias\].
\>
\> The latter comes from the idea that when you write e.g.
\>
\> UserId = int
\>
\> then UserId is a type alias (that's existing PEP 484 terminology) and
\> the type checker doesn't distinguish it from int -- you can use it in
\> places where you logically expect a UserId but to the type checker
\> those variables have the type int.
\>
\> There is even a neat potential "origin story" that would explain why
\> we'd call it Distinguished Type Alias.
\>
\> The story is about gradually converting a large code base to being
\> consistent: initially you make UserId a regular type alias and you
\> start putting it in your code incrementally, making sure it has no
\> mypy errors as you go (but this just treats it as an int). After days,
\> when you think you are done, you change UserId to a distinguished type
\> alias and then mypy will point out the places where you've missed
\> something or you're doing something questionable with user IDs.
\>
\> And yes, in the wider context of subclassing, Derived Type is probably
\> confusing because a subclass is also called a derived class.
\>
\>
\> On Sat, May 28, 2016 at 5:24 AM, Steven D'Aprano <steve@pearwood.info>
\> wrote:
\>> On Fri, May 27, 2016 at 09:26:29PM -0700, Guido van Rossum wrote:
\>>
\>>> We discussed this over dinner at PyCon, some ideas we came up with:
\>>>
\>>> - Dependent types, harking back to a similar concept in Ada
\>>> (https://en.wikibooks.org/wiki/Ada\_Programming/Type\_System#Derived\_types)
\>>> which in that language is also spelled with "new".
\>>
\>> I started to explain this to my non-programmer wife, I got as far as
\>> explaining types, and that we need a name for this thing, and she
\>> stopped me and said
\>>
\>> "Please don't tell me this is leading to TypyMcTypeCheck."
\>>
\>> \[...\]
\>>> - BoatyMcBoatType
\>>
\>>> The nice thing about "distinguished" is that it's a relatively rare
\>>> word so it is easy to remember or look up.
\>>
\>> I would have thought that being rare, it would be \*harder\* to remember.
\>>
\>>
\>>> Personally I'm still in favor of Derived type (but I'm more into
\>>> ancient programming languages than most folks here). I could also live
\>>> with Distinguished Type.
\>>
\>> I think Derived Type is the nicest of the options. It accurately
\>> describes what it is: a type derived from another. And its shorter and
\>> easy to both say and write than "Distinguished type" (which sounds like
\>> "distinguished gentlemen" -- is it wearing a monocle and a top hat?).
\>>
\>> "Distinguished" is too vague for my tastes, it might as well be
\>> "flibblegubble type". \*All\* types are distinguished, the type checker
\>> has to distinguish int from float from list from str, so to call
\>> NewType("userid", int) a "distinguished type" is only to call it a type.
\>>
\>>
\>>
\>> --
\>> Steve
\>> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\>> Python-Dev mailing list
\>> Python-Dev@python.org
\>> https://mail.python.org/mailman/listinfo/python-dev
\>> Unsubscribe:
\>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
\>
\>
\>
\> --
\> --Guido van Rossum (python.org/\~guido)
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> Python-Dev mailing list
\> Python-Dev@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe:
\> https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org



\--
\--Guido van Rossum (python.org/\~guido)
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev

Unsubscribe: https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/pludemann%40google.com