Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread André Malo 
* 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
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Steven D'Aprano 
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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Guido van Rossum 
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  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
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Steve Dower 
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" 
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  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
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Ivan Levkivskyi 
On 28 May 2016 at 06:26, Guido van Rossum  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
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Ivan Levkivskyi 
There is another interesting idea from Twitter: call them type wrappers.

--
Ivan

On 28 May 2016 at 11:01, Ivan Levkivskyi  wrote:
>
> On 28 May 2016 at 06:26, Guido van Rossum  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
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Guido van Rossum 
Oh, another D-word! I really like distinct.

On Sat, May 28, 2016 at 8:19 AM, Steve Dower  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 
> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Ivan Levkivskyi 
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"  пише:

> Oh, another D-word! I really like distinct.
>
> On Sat, May 28, 2016 at 8:19 AM, Steve Dower 
> 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 
> > 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
> >> [email protected]
> >> 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
> > [email protected]
> > 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
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/arc

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Peter Ludemann via Python-Dev 
I'm surprised that nobody has suggested UniqueType. ;)


On 28 May 2016 at 10:17, Ivan Levkivskyi  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"  пише:
>
>> Oh, another D-word! I really like distinct.
>>
>> On Sat, May 28, 2016 at 8:19 AM, Steve Dower 
>> 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 
>> > 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
>> >> [email protected]
>> >> 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
>> > [email protected]
>> > 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
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/optio

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Stephen J. Turnbull 
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.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Bernardo Sulzbach 

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".


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Christian Heimes 
On 2016-05-27 03:44, Victor Stinner wrote:
> Le 27 mai 2016 12:05 PM, "Donald Stufft"  > a écrit :
>> BLAKE2 is an interesting one, because while SHA3 is a NIST standard
> (so it’s going to gain adoption because of that), BLAKE2 is at least as
> strong as SHA3 but is better in many ways, particularly in speed— it’s
> actually faster than MD5 while being as secure as SHA3.
> 
> BLAKE2 was part of the SHA3 competition and it was in finalists. The
> SHA3 competition is interesting because each algorithm is deeply tested
> and analyzed by many teams all around the world. Obvious vulnerabilities
> are quickly found.

Thanks Victor,

minor correction, BLAKE was a finalist in the SHA3 competition, not
BLAKE2. BLAKE2 is an improved version of BLAKE2 with additional features.

Christian

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Christian Heimes 
On 2016-05-27 03:54, M.-A. Lemburg wrote:
> On 27.05.2016 06:54, Raymond Hettinger wrote:
>>
>>> On May 25, 2016, at 3:29 AM, Christian Heimes  wrote:
>>>
>>> I have three hashing-related patches for Python 3.6 that are waiting for
>>> review. Altogether the three patches add ten new hash algorithms to the
>>> hashlib module: SHA3 (224, 256, 384, 512), SHAKE (SHA3 XOF 128, 256),
>>> BLAKE2 (blake2b, blake2s) and truncated SHA512 (224, 256).
>>
>> Do we really need ten?  I don't think the standard library is the place to 
>> offer all variants of hashing.  And we should avoid getting in a cycle of 
>> "this was just released by NIST" and "nobody uses that one anymore".  Is any 
>> one of them an emergent best practice (i.e. starting to be commonly used in 
>> network protocols because it is better, faster, stronger, etc)?
>>
>> Your last message on https://bugs.python.org/issue16113 suggests that these 
>> aren't essential and that there is room for debate about whether some of 
>> them are standard-library worthy (i.e. we will have them around forever).
> 
> I can understand your eagerness to get this landed, since it's
> been 4 years since work started, but I think we should wait with
> the addition until OpenSSL has them:
> 
> https://github.com/openssl/openssl/issues/439
> 
> The current patch is 1.2MB for SHA-3 - that's pretty heavy for just
> a few hash functions, which aren't in any wide spread use yet and
> probably won't be for quite a few years ahead.

About 1 MB of the 1.2 MB are test vectors for SHA3. Strictly speaking
the test vectors are not required.

> IMO, relying on OpenSSL is a better strategy than providing
> (and maintaining) our own compatibility versions. Until OpenSSL
> has them, people can use Björn's package:
> 
> https://github.com/bjornedstrom/python-sha3
> 
> Perhaps you could join forces with Björn to create a standard
> SHA-3 standalone package on PyPI based on your two variants
> which we could recommend to people in the docs ?!

I have been maintaining my own SHA3 module for couple of years. A month
ago I moved my code to github and ported it to the new Keccak Code
Package. The standalone package uses the same code as my patch but also
provides the old Keccak hashes and works on Python 2.7.

https://github.com/tiran/pysha3
https://pypi.python.org/pypi/pysha3
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Christian Heimes 
On 2016-05-27 09:41, Chris Barker wrote:
> I'm probably showing my ignorance here, but couldn't we swap in the
> OpenSSL implementation when that becomes available?

No, not any time soon. As soon as we guarantee SHA3 support we have to
keep our own implementation for a couple of additional releases. We can
drop our own SHA3 code as soon as all supported OpenSSL versions have SHA3.

For example when OpenSSL 1.2.0 is going to have SHA3 support, we must
wait until OpenSSL 1.1 and 1.0.2 are no longer supported by OpenSSL.

Christian


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Donald Stufft 

> On May 28, 2016, at 5:01 PM, Christian Heimes  wrote:
> 
> No, not any time soon. As soon as we guarantee SHA3 support we have to
> keep our own implementation for a couple of additional releases. We can
> drop our own SHA3 code as soon as all supported OpenSSL versions have SHA3.


It still will be needed for as long as it’s possible to build Python without
OpenSSL.

—
Donald Stufft



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Brett Cannon 
On Sat, May 28, 2016, 13:58 Christian Heimes  wrote:

> On 2016-05-27 03:54, M.-A. Lemburg wrote:
> > On 27.05.2016 06:54, Raymond Hettinger wrote:
> >>
> >>> On May 25, 2016, at 3:29 AM, Christian Heimes 
> wrote:
> >>>
> >>> I have three hashing-related patches for Python 3.6 that are waiting
> for
> >>> review. Altogether the three patches add ten new hash algorithms to the
> >>> hashlib module: SHA3 (224, 256, 384, 512), SHAKE (SHA3 XOF 128, 256),
> >>> BLAKE2 (blake2b, blake2s) and truncated SHA512 (224, 256).
> >>
> >> Do we really need ten?  I don't think the standard library is the place
> to offer all variants of hashing.  And we should avoid getting in a cycle
> of "this was just released by NIST" and "nobody uses that one anymore".  Is
> any one of them an emergent best practice (i.e. starting to be commonly
> used in network protocols because it is better, faster, stronger, etc)?
> >>
> >> Your last message on https://bugs.python.org/issue16113 suggests that
> these aren't essential and that there is room for debate about whether some
> of them are standard-library worthy (i.e. we will have them around forever).
> >
> > I can understand your eagerness to get this landed, since it's
> > been 4 years since work started, but I think we should wait with
> > the addition until OpenSSL has them:
> >
> > https://github.com/openssl/openssl/issues/439
> >
> > The current patch is 1.2MB for SHA-3 - that's pretty heavy for just
> > a few hash functions, which aren't in any wide spread use yet and
> > probably won't be for quite a few years ahead.
>
> About 1 MB of the 1.2 MB are test vectors for SHA3. Strictly speaking
> the test vectors are not required.
>

We can always make the test vector file an external download like we do for
some of the codec tests.

-brett



> > IMO, relying on OpenSSL is a better strategy than providing
> > (and maintaining) our own compatibility versions. Until OpenSSL
> > has them, people can use Björn's package:
> >
> > https://github.com/bjornedstrom/python-sha3
> >
> > Perhaps you could join forces with Björn to create a standard
> > SHA-3 standalone package on PyPI based on your two variants
> > which we could recommend to people in the docs ?!
>
> I have been maintaining my own SHA3 module for couple of years. A month
> ago I moved my code to github and ported it to the new Keccak Code
> Package. The standalone package uses the same code as my patch but also
> provides the old Keccak hashes and works on Python 2.7.
>
> https://github.com/tiran/pysha3
> https://pypi.python.org/pypi/pysha3
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Guido van Rossum 
But you could choose which implementation to use at compile time based
on the autoconf output, right?

On Sat, May 28, 2016 at 2:01 PM, Christian Heimes  wrote:
> On 2016-05-27 09:41, Chris Barker wrote:
>> I'm probably showing my ignorance here, but couldn't we swap in the
>> OpenSSL implementation when that becomes available?
>
> No, not any time soon. As soon as we guarantee SHA3 support we have to
> keep our own implementation for a couple of additional releases. We can
> drop our own SHA3 code as soon as all supported OpenSSL versions have SHA3.
>
> For example when OpenSSL 1.2.0 is going to have SHA3 support, we must
> wait until OpenSSL 1.1 and 1.0.2 are no longer supported by OpenSSL.
>
> Christian
>
>
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Christian Heimes 
On 2016-05-27 14:41, M.-A. Lemburg wrote:
> On 27.05.2016 22:58, Ryan Gonzalez wrote:
>> On May 27, 2016 3:04 PM, "Victor Stinner"  wrote:
>>>
>>> Le vendredi 27 mai 2016, M.-A. Lemburg  a écrit :

 The current patch is 1.2MB for SHA-3 - that's pretty heavy for just
 a few hash functions, which aren't in any wide spread use yet and
 probably won't be for quite a few years ahead.
>>>
>>>
>>> Oh wow, it's so fat? Why is it so big? Can't we use a lighter version?
>>>
>>
>> The stark majority of the patch is Lib/test/vectors/sha3_224.txt, which
>> seems to be (as the file path implies) just test data. A whopping >1k LOC
>> of really long hashes.
> 
> Right. There's about 1MB test data in the patch, but even
> without that data, the patch adds more than 6400 lines of code.

The KeccakCodePackage is rather large. I already removed all unnecessary
files and modified some files so more code is shared between 32 and
64bit optimized variants. Please keep in mind that the KCP contains
multiple implementations with different optimizations for CPU
architectures. I already removed the ARM NEON optimization.
I also don't get your obsession with lines of code. The gzip and expat
are far bigger than the KeccakCodePackage.


> If we add this now, there should at least be an exit strategy
> to remove the code again, when OpenSSL ships with the same
> code, IMO.
> 
> Aside: BLAKE2 has already landed in OpenSSL 1.1.0:
> 
> https://github.com/openssl/openssl/tree/master/crypto/blake2

Except BLAKE2 in OpenSSL is severely castrated and tailored towards a
very limited use case. The implementation does not support any of the
useful advanced features like keyed hashing (MAC), salt,
personalization, tree hashing and variable hash length.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Donald Stufft 

> On May 28, 2016, at 5:06 PM, Guido van Rossum  wrote:
> 
> But you could choose which implementation to use at compile time based
> on the autoconf output, right?

I think we should follow what hashlib already does. If we want to change the 
way it works that's fine but these hashes shouldn't be special. They should 
work the way that all the other standard hashes in hashlib work. 
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Christian Heimes 
On 2016-05-28 14:06, Guido van Rossum wrote:
> But you could choose which implementation to use at compile time based
> on the autoconf output, right?

We compile all modules and then let hashlib decide which implementation
is used. hashlib prefers OpenSSL but falls back to our builtin modules.
For MD5, SHA1 and SHA2 OpenSSL's implementation has better performance
(up to twice the speed).

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Christian Heimes 
On 2016-05-28 14:06, Brett Cannon wrote:
> We can always make the test vector file an external download like we do
> for some of the codec tests.

That is actually a great idea! :)

Thanks Brett

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Christian Heimes 
On 2016-05-27 15:52, Nathaniel Smith wrote:
> On Fri, May 27, 2016 at 3:08 PM, M.-A. Lemburg  wrote:
>> On 27.05.2016 23:46, Donald Stufft wrote:
>>>
 On May 27, 2016, at 5:41 PM, M.-A. Lemburg  wrote:

 If we add this now, there should at least be an exit strategy
 to remove the code again, when OpenSSL ships with the same
 code, IMO.
>>>
>>> I think it is a clear win to have the fallback implementations in cases 
>>> where people either don’t have OpenSSL or don’t have a new enough OpenSSL 
>>> for those implementations. Not having the fallback just makes it more 
>>> difficult for people to rely on those hash functions.
>>
>> This will only be needed once the stdlib itself starts requiring
>> support for some of these hashes and for that we could add
>> a pure Python implementation, eg.
>>
>> https://github.com/coruus/py-keccak
>>
>> In all other cases, you can simply add the support via a
>> package such as Björn's or Christian's.
> 
> SHA-3 and BLAKE are extremely widely accepted standards, our users
> will expect them, and they're significant improvements over all the
> current hashes in the algorithms_guaranteed list. If we demote them to
> second-class support (by making them only available in some builds, or
> using a slow pure Python implementation), then we'll be encouraging
> users to use inferior hashes. We shouldn't do this without a very good
> reason, and I don't see anything very convincing here... by all means
> drop the megabyte of test data, but why does it matter how many lines
> of code the algorithm is? No python developer will ever have to look
> at it -- hash code by its nature is *very* low maintenance (it either
> computes the right function or it doesn't, and the right answer never
> changes). And in unlikely case where some terrible unexpected bug is
> discovered then the only maintenance needed will be to delete the
> current impl and drop-in whatever the new fixed one is.
> 
> So +1 to adding SHA-3 and BLAKE to algorithms_guaranteed.

Thanks Nathaniel,

my patches don't add SHA3 and BLAKE2 to algorithms_guaranteed because
Python still supports C89 platforms without a 64 bit integer type.
Theoretically 64bit ints are not required except for BLAKE2b. Since
Trent's snakebite.org is dead I don't have access to these old platforms
any more.

Christian
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Chris Jerdonek 
On Fri, May 27, 2016 at 9:26 PM, 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".
>
> - 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread cs 

On 28May2016 08:19, Steve Dower  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 <[email protected]>, 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 
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding NewType() to PEP 484

2016-05-28 Thread Ivan Levkivskyi 
Type clone sounds good. But I am still inclined more towards "distinct".

--
Ivan
29 Тра 2016 01:04 "Chris Jerdonek"  пише:

> On Fri, May 27, 2016 at 9:26 PM, 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".
> >
> > - 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
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

2016-05-28 Thread Victor Stinner 
Python 3.5 requires a 64 bit signed integer to build. Search for _PyTime
type in pytime.h ;-)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com