Hi, It has been proposed to enhance the typing module with a NewType function that allows to define simple unique types with almost zero runtime overhead. The PR containing actual implementation and PEP 484 update is here: https://github.com/python/typing/pull/226 Review comments are very welcome. Best regards, Ivan
Patches to Python's stdlib should go through bugs.python.org so it isn't lost in email. On Fri, May 27, 2016, 12:00 Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
Hi,
It has been proposed to enhance the typing module with a NewType function that allows to define simple unique types with almost zero runtime overhead.
The PR containing actual implementation and PEP 484 update is here: https://github.com/python/typing/pull/226
Review comments are very welcome.
Best regards, Ivan _______________________________________________ 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/brett%40python.org
Sorry, this is more meant to be the start of a discussion about the proposed feature. And typing.py has its own upstream repo (like asyncio). --Guido (mobile) On May 27, 2016 12:52 PM, "Brett Cannon" <brett@python.org> wrote:
Patches to Python's stdlib should go through bugs.python.org so it isn't lost in email.
On Fri, May 27, 2016, 12:00 Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
Hi,
It has been proposed to enhance the typing module with a NewType function that allows to define simple unique types with almost zero runtime overhead.
The PR containing actual implementation and PEP 484 update is here: https://github.com/python/typing/pull/226
Review comments are very welcome.
Best regards, Ivan _______________________________________________ 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/brett%40python.org
_______________________________________________ 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
Also -- the most important thing. :-) What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward. On Fri, May 27, 2016 at 12:54 PM, Guido van Rossum <gvanrossum@gmail.com> wrote:
Sorry, this is more meant to be the start of a discussion about the proposed feature. And typing.py has its own upstream repo (like asyncio).
--Guido (mobile)
On May 27, 2016 12:52 PM, "Brett Cannon" <brett@python.org> wrote:
Patches to Python's stdlib should go through bugs.python.org so it isn't lost in email.
On Fri, May 27, 2016, 12:00 Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
Hi,
It has been proposed to enhance the typing module with a NewType function that allows to define simple unique types with almost zero runtime overhead.
The PR containing actual implementation and PEP 484 update is here: https://github.com/python/typing/pull/226
Review comments are very welcome.
Best regards, Ivan _______________________________________________ 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/brett%40python.org
_______________________________________________ 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)
On Fri, May 27, 2016 at 04:01:11PM -0700, Guido van Rossum wrote:
Also -- the most important thing. :-) What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
TypeAlias? Because A is an alias for int? -- Steve
On Fri, May 27, 2016 at 6:59 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Steven D'Aprano wrote:
TypeAlias? Because A is an alias for int?
That suggests it's just another name for the same type, but it's not. It's a distinct type as far as the static type checker is concerned.
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". - New type - Distinguished Type - Distinguished Subtype - Distinguished Type Alias - Distinguished Alias - BoatyMcBoatType The nice thing about "distinguished" is that it's a relatively rare word so it is easy to remember or look up. 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. The problem with Alias is that these types are *not* aliases (at least not to the type checker, which is where we need the terminology -- so we can talk about what the type checker does to these).
Fake types? Virtual types? Pseudo-types?
I'm not keen on any of these. -- --Guido van Rossum (python.org/~guido)
On 28 May 2016 at 06:26, Guido van Rossum <guido@python.org> wrote:
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 both "derived" and "distinguished" are OK, but I am more in favour of "distinguished". The reason is sometimes people might talk about derived types while meaning normal derived classes. Also, indeed "distinguished" is a rare word, so that it will not cause confusions and easy to look up. -- Ivan
There is another interesting idea from Twitter: call them type wrappers. -- Ivan On 28 May 2016 at 11:01, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 28 May 2016 at 06:26, Guido van Rossum <guido@python.org> wrote:
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 both "derived" and "distinguished" are OK, but I am more in
favour of "distinguished".
The reason is sometimes people might talk about derived types while meaning normal derived classes. Also, indeed "distinguished" is a rare word, so that it will not cause confusions and easy to look up.
-- Ivan
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
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)
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 -----Original Message----- From: "Guido van Rossum" <guido@python.org> Sent: 5/28/2016 7:38 To: "Steven D'Aprano" <steve@pearwood.info> Cc: "Python-Dev" <python-dev@python.org> 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
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)
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
I'm surprised that nobody has suggested UniqueType. ;) On 28 May 2016 at 10:17, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
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.
Did anyone suggest "distinct type alias"?
Regardless of what name, I'm fairly sure people will call it whatever
On Sat, May 28, 2016 at 8:19 AM, Steve Dower <steve.dower@python.org> wrote: 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
On 05/28/2016 12:19 PM, Steve Dower wrote:
Did anyone suggest "distinct type alias"?
I would just like to mention that "distinguished" seems to be more often associated with notability and excellence than "distinct", which is usually more neutral towards the quality of what it describes. Unless we want to say that these types are nobler than their counterparts, "distinguished" seems worse than "distinct".
On 28May2016 08:19, 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.
Just casting an opinion in support of Greg Ewing's remark: I don't think we should use the word "alias", regardless of what else is used. In <5748FB66.7090107@canterbury.ac.nz>, Greg said: Steven D'Aprano wrote:
TypeAlias? Because A is an alias for int? That suggests it's just another name for the same type, but it's not. It's a distinct type as far as the static type checker is concerned
and I agree entirely. Cheers, Cameron Simpson <cs@zip.com.au>
The aspects we want to capture in a name or adjective for these types are: a) The types have identical implementations or definitions. b) They are distinct types. I think “Distinguished Type” or”Cloned Type” best captures these qualities. I think the following also capture the quality, but feel a bit pejorative. "Segregated Type" "Arbitrary Type" Jonathan
On 5/29/2016 12:57 PM, jon wrote:
The aspects we want to capture in a name or adjective for these types are:
a) The types have identical implementations or definitions. b) They are distinct types.
I think “Distinguished Type” or”Cloned Type” best captures these qualities.
'Cloned Type' conveys the meaning above, "Distinguished Type' does not, unless one knows what it us supposed to mean. One meaning is 'distinct because superior (or inferior)'.
I think the following also capture the quality, but feel a bit pejorative.
"Segregated Type" "Arbitrary Type"
Things are segregated because they are thought to be different. 'Arbitrary' means that it could be anything ;-). -- Terry Jan Reedy
On 5/29/2016 9:57 AM, jon wrote:
The aspects we want to capture in a name or adjective for these types are:
a) The types have identical implementations or definitions. b) They are distinct types.
I think “Distinguished Type” or”Cloned Type” best captures these qualities.
I think the following also capture the quality, but feel a bit pejorative.
"Segregated Type" "Arbitrary Type"
"Exclusive Type" "Separate Type" Glenn
Guido van Rossum writes:
But seriously I think we should just decide between Derived Type and Distinguished Type [Alias].
I like "typedef", but I'm pretty sure it wouldn't carry the same connotations to people who aren't C programming oldtimers. I dislike "derived" because that fits stuff like Union[int, str] or List[int] *better* than NewType("A", int). Bottom line: +1 for distinguished. I may have a little trouble remembering that NewType creates Distinguished Types (do they get a medal from the Queen, by the way?), but if you call something a "distinguished type" I will have zero trouble remembering that it's a new type created out of thin air by distinguishing it from an existing type.
On Fri, May 27, 2016 at 9:26 PM, Guido van Rossum <guido@python.org> 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".
- New type
- Distinguished Type
- Distinguished Subtype
- Distinguished Type Alias
- Distinguished Alias
- BoatyMcBoatType
Some more suggestions: - Cloned Type (or Type Clone) - Copied Type (or Type Copy) - Named Type - Renamed Type - Twin Type - Wrapped Type - Doppelganger Type (not serious) --Chris
Type clone sounds good. But I am still inclined more towards "distinct". -- Ivan 29 Тра 2016 01:04 "Chris Jerdonek" <chris.jerdonek@gmail.com> пише:
On Fri, May 27, 2016 at 9:26 PM, Guido van Rossum <guido@python.org> 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".
- New type
- Distinguished Type
- Distinguished Subtype
- Distinguished Type Alias
- Distinguished Alias
- BoatyMcBoatType
Some more suggestions:
- Cloned Type (or Type Clone)
- Copied Type (or Type Copy)
- Named Type
- Renamed Type
- Twin Type
- Wrapped Type
- Doppelganger Type (not serious)
--Chris _______________________________________________ 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
* Steven D'Aprano wrote:
On Fri, May 27, 2016 at 04:01:11PM -0700, Guido van Rossum wrote:
Also -- the most important thing. :-) What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
TypeAlias? Because A is an alias for int?
I like the view C takes on this: typedef. Cheers, -- Wer sein Wissen nicht teilen will, besitzt wahrscheinlich zu wenig davon. -- Unbekannt
Guido van Rossum wrote:
Also -- the most important thing. :-) What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
Fake types? Virtual types? Pseudo-types? -- Greg
2016-05-27 16:01 GMT-07:00 Guido van Rossum <gvanrossum@gmail.com>:
Also -- the most important thing. :-) What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
For what it's worth, Haskell uses the term "newtype" for a very similar concept (https://wiki.haskell.org/Newtype), so maybe Python should follow suit in the interest of not creating new confusing terminology. "Dependent type" (proposed by a few people) already means something else ( https://en.wikipedia.org/wiki/Dependent_type), so it doesn't seem like a good choice here.
Sorry, this is more meant to be the start of a discussion about the
On Fri, May 27, 2016 at 12:54 PM, Guido van Rossum <gvanrossum@gmail.com> wrote: proposed
feature. And typing.py has its own upstream repo (like asyncio).
--Guido (mobile)
On May 27, 2016 12:52 PM, "Brett Cannon" <brett@python.org> wrote:
Patches to Python's stdlib should go through bugs.python.org so it
isn't
lost in email.
On Fri, May 27, 2016, 12:00 Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
Hi,
It has been proposed to enhance the typing module with a NewType
function
that allows to define simple unique types with almost zero runtime overhead.
The PR containing actual implementation and PEP 484 update is here: https://github.com/python/typing/pull/226
Review comments are very welcome.
Best regards, Ivan _______________________________________________ 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/brett%40python.org
_______________________________________________ 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/jelle.zijlstra%40gmail.co...
On Sun, May 29, 2016 at 12:07 PM, Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
2016-05-27 16:01 GMT-07:00 Guido van Rossum <gvanrossum@gmail.com>:
Also -- the most important thing. :-) What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
For what it's worth, Haskell uses the term "newtype" for a very similar concept (https://wiki.haskell.org/Newtype), so maybe Python should follow suit in the interest of not creating new confusing terminology.
Yeah, I started out rejecting this because I don't like such neologisms.
"Dependent type" (proposed by a few people) already means something else (https://en.wikipedia.org/wiki/Dependent_type), so it doesn't seem like a good choice here.
I apologize, when I brought that up I meant to say "derived type" (as should have been clear from the link I provided (https://en.wikibooks.org/wiki/Ada_Programming/Type_System#Derived_types). I agree dependent types would be a terrible name here. :-) I am currently in favor of Distinct Type [Alias]. -- --Guido van Rossum (python.org/~guido)
On Sun, May 29, 2016 at 4:53 PM, Guido van Rossum <gvanrossum@gmail.com> wrote:
I am currently in favor of Distinct Type [Alias].
I actually like distinguished type better: A = typing.distinguish("A", int) -Fred -- Fred L. Drake, Jr. <fred at fdrake.net> "A storm broke loose in my mind." --Albert Einstein
On 28 May 2016 00:03, "Guido van Rossum" <gvanrossum@gmail.com> wrote:
Also -- the most important thing. :-) What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
How about "nominal type" since the type is distinct only in name? -- Oscar
On Sun, May 29, 2016 at 4:08 PM, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
On 28 May 2016 00:03, "Guido van Rossum" <gvanrossum@gmail.com> wrote:
Also -- the most important thing. :-) What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
How about "nominal type" since the type is distinct only in name?
I believe that would be confusing because nominal type systems are a different idea (https://en.wikipedia.org/wiki/Nominal_type_system). -- --Guido van Rossum (python.org/~guido)
Guido van Rossum <gvanrossum <at> gmail.com> writes:
Also -- the most important thing. What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
back in high school, i was introduced to c programming with the "disciplined C" preprocessor [0]. it made the distinction between information type and representation type (e.g. between the semantic and the implementation). those new types where created using typedefs and were named 'parallel types' below is the relevant part of the dcc presentation: """ a major innovation of Disciplined C is the notion of "parallel type", that allows a distinction between information type and representation type. The following: typedef int Tindex, Tval; typedef Tindex Trow, Tcol; creates four distinct types, but which all accept the same operations and the same constants as the "representation" type ('int' here). Tindex, Tval, Trow and Tcol are examples of "information" types, because they convey an idea of the semantics of the corresponding objects. For example, they may be put to use in a checkers playing program: Tval will name 'int's that represent values of checkers, Trow and Tcol, 'int's that represent row and column indexes, Tindex, generic type for indexes. Tindex, Tval, Trow and Tcol are called parallel types; in fact, a type T1 is said to be parallel to a type T2 iff both are defined through a chain of typedefs starting from the same 'baseType', with no intervening qualifier nor modifier (pointer/array/function decla- rator, see grammar in Appendix A). In other words, T and T2 must be strict synonyms of baseType. """ renaud 0. Disciplined C ACM SIGPLAN Notices Homepage archive Volume 30 Issue 12, Dec. 1995 Pages 43 - 50 http://dl.acm.org/citation.cfm?id=219726.219747 http://www.digiater.nl/openvms/freeware/v50/dcc/dcc-v2_7d/dccarticle.ps
On 5/31/2016 12:55 PM, rndblnch wrote:
Guido van Rossum <gvanrossum <at> gmail.com> writes:
Also -- the most important thing. What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward. back in high school, i was introduced to c programming with the "disciplined C" preprocessor [0]. it made the distinction between information type and representation type (e.g. between the semantic and the implementation). those new types where created using typedefs and were named 'parallel types' below is the relevant part of the dcc presentation:
Interesting! Prior art. And parallel type isn't a bad name...
""" a major innovation of Disciplined C is the notion of "parallel type", that allows a distinction between information type and representation type. The following:
typedef int Tindex, Tval; typedef Tindex Trow, Tcol;
creates four distinct types, but which all accept the same operations and the same constants as the "representation" type ('int' here). Tindex, Tval, Trow and Tcol are examples of "information" types, because they convey an idea of the semantics of the corresponding objects. For example, they may be put to use in a checkers playing program: Tval will name 'int's that represent values of checkers, Trow and Tcol, 'int's that represent row and column indexes, Tindex, generic type for indexes. Tindex, Tval, Trow and Tcol are called parallel types; in fact, a type T1 is said to be parallel to a type T2 iff both are defined through a chain of typedefs starting from the same 'baseType', with no intervening qualifier nor modifier (pointer/array/function decla- rator, see grammar in Appendix A). In other words, T and T2 must be strict synonyms of baseType. """
renaud
0. Disciplined C
ACM SIGPLAN Notices Homepage archive Volume 30 Issue 12, Dec. 1995 Pages 43 - 50 http://dl.acm.org/citation.cfm?id=219726.219747 http://www.digiater.nl/openvms/freeware/v50/dcc/dcc-v2_7d/dccarticle.ps
_______________________________________________ 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/v%2Bpython%40g.nevcal.com
On 31 May 2016 3:12 pm, "Glenn Linderman" <v+python@g.nevcal.com> wrote:
On 5/31/2016 12:55 PM, rndblnch wrote:
Guido van Rossum <gvanrossum <at> gmail.com> writes:
Also -- the most important thing. What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
back in high school, i was introduced to c programming with the
"disciplined
C" preprocessor [0]. it made the distinction between information type and representation type (e.g. between the semantic and the implementation). those new types where created using typedefs and were named 'parallel types' below is the relevant part of the dcc presentation:
Interesting! Prior art. And parallel type isn't a bad name...
If I heard "parallel type", I'd assume it had something to do with parallel processing. Of the options suggested so far, DistinctType seems the most promising to me. Cheers, Nick.
""" a major innovation of Disciplined C is the notion of "parallel type",
that
allows a distinction between information type and representation type. The following:
typedef int Tindex, Tval; typedef Tindex Trow, Tcol;
creates four distinct types, but which all accept the same operations and the same constants as the "representation" type ('int' here). Tindex, Tval, Trow and Tcol are examples of "information" types, because they convey an idea of the semantics of the corresponding objects. For example, they may be put to use in a checkers playing program: Tval will name 'int's that represent values of checkers, Trow and Tcol, 'int's that represent row and column indexes, Tindex, generic type for indexes. Tindex, Tval, Trow and Tcol are called parallel types; in fact, a type T1 is said to be parallel to a type T2 iff both are defined through a chain of typedefs starting from the same 'baseType', with no intervening qualifier nor modifier (pointer/array/function decla- rator, see grammar in Appendix A). In other words, T and T2 must be strict synonyms of baseType. """
renaud
0. Disciplined C
ACM SIGPLAN Notices Homepage archive Volume 30 Issue 12, Dec. 1995 Pages 43 - 50 http://dl.acm.org/citation.cfm?id=219726.219747 http://www.digiater.nl/openvms/freeware/v50/dcc/dcc-v2_7d/dccarticle.ps
_______________________________________________ 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/v%2Bpython%40g.nevcal.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/ncoghlan%40gmail.com
On 5/31/2016 4:58 PM, Nick Coghlan wrote:
On 31 May 2016 3:12 pm, "Glenn Linderman" <v+python@g.nevcal.com <mailto:v%2Bpython@g.nevcal.com>> wrote:
On 5/31/2016 12:55 PM, rndblnch wrote:
Guido van Rossum <gvanrossum <at> gmail.com <http://gmail.com>> writes:
Also -- the most important thing. What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
back in high school, i was introduced to c programming with the
"disciplined
C" preprocessor [0]. it made the distinction between information type and representation type (e.g. between the semantic and the implementation). those new types where created using typedefs and were named 'parallel types' below is the relevant part of the dcc presentation:
Interesting! Prior art. And parallel type isn't a bad name...
If I heard "parallel type", I'd assume it had something to do with parallel processing.
Google seems to think so also... "Disciplined C" probably predates parallel processing, but adding disciplined C preprocessor to the search does find a document about the preprocessor in the same sense used by @rndblnch. And the types do have "parallel" behavior... every behavior of one is found identically in the other. So it makes sense, but it would be hard to find the prior art without extra information, as the term is now overwhelmed by "Parallel Type-checking" for parallel processing. Still, some mention should probably be made of "parallel type in the 'Disciplined C preprocessor' " in the "prior art" category of PEP 484. From reading about Disciplined C, would seem that this feature could be used as a foundation to add "units" support to variables, validated only by a type checker, and thus having no runtime overhead, although it would take some more features from Disciplined C, regarding the definition of legal combinations of types and operations.
Of the options suggested so far, DistinctType seems the most promising to me.
Cheers, Nick.
""" a major innovation of Disciplined C is the notion of "parallel
allows a distinction between information type and representation type. The following:
typedef int Tindex, Tval; typedef Tindex Trow, Tcol;
creates four distinct types, but which all accept the same operations and the same constants as the "representation" type ('int' here). Tindex, Tval, Trow and Tcol are examples of "information" types, because they convey an idea of the semantics of the corresponding objects. For example,
type", that they may be
put to use in a checkers playing program: Tval will name 'int's that represent values of checkers, Trow and Tcol, 'int's that represent row and column indexes, Tindex, generic type for indexes. Tindex, Tval, Trow and Tcol are called parallel types; in fact, a type T1 is said to be parallel to a type T2 iff both are defined through a chain of typedefs starting from the same 'baseType', with no intervening qualifier nor modifier (pointer/array/function decla- rator, see grammar in Appendix A). In other words, T and T2 must be strict synonyms of baseType. """
renaud
0. Disciplined C
ACM SIGPLAN Notices Homepage archive Volume 30 Issue 12, Dec. 1995 Pages 43 - 50 http://dl.acm.org/citation.cfm?id=219726.219747 http://www.digiater.nl/openvms/freeware/v50/dcc/dcc-v2_7d/dccarticle.ps
_______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
On 05/31/2016 08:58 PM, Nick Coghlan wrote:
On 31 May 2016 3:12 pm, "Glenn Linderman" <v+python@g.nevcal.com> wrote:
On 5/31/2016 12:55 PM, rndblnch wrote:
Guido van Rossum <gvanrossum <at> gmail.com> writes:
Also -- the most important thing. What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them? "New types" sounds awkward.
back in high school, i was introduced to c programming with the
"disciplined
C" preprocessor [0]. it made the distinction between information type and representation type (e.g. between the semantic and the implementation). those new types where created using typedefs and were named 'parallel types' below is the relevant part of the dcc presentation:
Interesting! Prior art. And parallel type isn't a bad name...
If I heard "parallel type", I'd assume it had something to do with parallel processing.
This also happens to me every time I read it.
Nick Coghlan <ncoghlan <at> gmail.com> writes:
On 31 May 2016 3:12 pm, "Glenn Linderman" <v+python <at> g.nevcal.com> wrote:
On 5/31/2016 12:55 PM, rndblnch wrote:
Guido van Rossum <gvanrossum <at> gmail.com> writes:
Also -- the most important thing. What to call these things?
Interesting! Prior art. And parallel type isn't a bad name... If I heard "parallel type", I'd assume it had something to do with
[...] parallel processing. sure, it was 15 years ago, parallel processing was not so widely widespread. but looking at synonyms for parallel, i stumbed upon: counterpart, analog, miror, etc. and then from here: countertype ... my 2 cents. renaud [...]
Cheers, Nick.
Unless Jukka objects I am going with "distinct type" when discussing the feature but NewType() in code. -- --Guido van Rossum (python.org/~guido)
I am +1 for DistinctType (vs others) (no specific reason, just read out loud). Hai On Wednesday, June 1, 2016, Guido van Rossum <guido@python.org> wrote:
Unless Jukka objects I am going with "distinct type" when discussing the feature but NewType() in code.
-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org <javascript:;> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/nhai.qn%40gmail.com
Everyone on the mypy team has a different opinion so the search is on. :-( On Wed, Jun 1, 2016 at 5:37 PM, Hai Nguyen <nhai.qn@gmail.com> wrote:
I am +1 for DistinctType (vs others) (no specific reason, just read out loud).
Hai
On Wednesday, June 1, 2016, Guido van Rossum <guido@python.org> wrote:
Unless Jukka objects I am going with "distinct type" when discussing the feature but NewType() in code.
-- --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/nhai.qn%40gmail.com
-- --Guido van Rossum (python.org/~guido)
On 06/01/2016 09:44 PM, Guido van Rossum wrote:
Everyone on the mypy team has a different opinion so the search is on. :-(
On Wed, Jun 1, 2016 at 5:37 PM, Hai Nguyen <nhai.qn@gmail.com> wrote:
I am +1 for DistinctType (vs others) (no specific reason, just read out loud).
At least on this thread it seems like (I haven't counted) that distinct type [alias] is the preferred option.
I've merged this into PEP 484 now. The informal term used there is actually "unique type" which is fine. End of discussion please. On Wed, Jun 1, 2016 at 5:50 PM, Bernardo Sulzbach <mafagafogigante@gmail.com> wrote:
On 06/01/2016 09:44 PM, Guido van Rossum wrote:
Everyone on the mypy team has a different opinion so the search is on. :-(
On Wed, Jun 1, 2016 at 5:37 PM, Hai Nguyen <nhai.qn@gmail.com> wrote:
I am +1 for DistinctType (vs others) (no specific reason, just read out loud).
At least on this thread it seems like (I haven't counted) that distinct type [alias] is the preferred option. _______________________________________________ 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)
participants (22)
-
André Malo -
Bernardo Sulzbach -
Brett Cannon -
Chris Jerdonek -
cs＠zip.com.au -
Fred Drake -
Glenn Linderman -
Greg Ewing -
Guido van Rossum -
Guido van Rossum -
Hai Nguyen -
Ivan Levkivskyi -
Jelle Zijlstra -
jon -
Nick Coghlan -
Oscar Benjamin -
Peter Ludemann -
rndblnch -
Stephen J. Turnbull -
Steve Dower -
Steven D'Aprano -
Terry Reedy