Re: [Python-Dev] Python parser performance optimizations

[Steven D'Aprano]

On Thu, May 26, 2016 at 10:19:05AM +, Artyom Skrobov wrote:
[...]
> The motivation for this patch was to enable a memory footprint 
> optimization, discussed at http://bugs.python.org/issue26415 My 
> proposed optimization reduces the memory footprint by up to 30% on the 
> standard benchmarks, and by 200% on a degenerate case which sparked 
> the discussion. The run time stays unaffected by this optimization.

That can't be right. How can you reduce memory usage by more than one 
hundred percent? That would mean you have saved more memory than was 
originally used and are now using a negative amount of memory.


-- 
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/archive%40mail-archive.com

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

[Fred Drake]

On Sun, May 29, 2016 at 4:53 PM, Guido van Rossum  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.
"A storm broke loose in my mind."  --Albert Einstein
___
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/archive%40mail-archive.com

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

[Guido van Rossum]

On Sun, May 29, 2016 at 4:08 PM, Oscar Benjamin
 wrote:
>
> On 28 May 2016 00:03, "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.
>
> 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)
___
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/archive%40mail-archive.com

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

[Guido van Rossum]

On Sun, May 29, 2016 at 12:07 PM, Jelle Zijlstra
 wrote:
>
>
> 2016-05-27 16:01 GMT-07:00 Guido van Rossum :
>>
>> 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)
___
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/archive%40mail-archive.com

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

[Oscar Benjamin]

On 28 May 2016 00:03, "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.

How about "nominal type" since the type is distinct only in name?

--
Oscar
___
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/archive%40mail-archive.com

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

[Christian Heimes]

On 2016-05-28 23:51, Victor Stinner wrote:
> Python 3.5 requires a 64 bit signed integer to build. Search for _PyTime
> type in pytime.h ;-)

Awesome! Thanks :)

___
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/archive%40mail-archive.com

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

[Jelle Zijlstra]

2016-05-27 16:01 GMT-07:00 Guido van Rossum :

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

>
> On Fri, May 27, 2016 at 12:54 PM, Guido van Rossum 
> 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"  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 
> 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.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/archive%40mail-archive.com

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

[Terry Reedy]

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


___
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/archive%40mail-archive.com

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

[jon]

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

___
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/archive%40mail-archive.com

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

[M.-A. Lemburg]

On 28.05.2016 23:13, Christian Heimes wrote:
> 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.

For a small piece of code, it's fine to have a copy in the
stdlib, but for larger chunks such as this one, I think we
ought to consider alternative options, since I don't think
it's good to have to carry around this baggage forever.

OpenSSL will eventually have good enough support for what
most Python users will need from these new hash functions.
That's why I think it's better to have a discussion of whether
we need to full package in the stdlib or better only provide
limited support built into the stdlib and refer people to
PyPI packages for things that you don't need every day.

Regarding the stories for zlib and expat, I only remember
that expat was essentially unmaintained when we added it
and the existing version at the time had known bugs (but
could be wrong).

For zlib, I have no clue as to why we have a copy in the stdlib.
That lib is available on all systems nowadays. Perhaps it wasn't
when we added it; don't remember. If so, it's a good example of
why adding copies to the stdlib is not such a good idea :-)

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

I bet that the use cases they put into OpenSSL is what
most people will eventually use, so essentially the same
reasoning we use for putting stuff into the stdlib.

Besides, the code just landed in OpenSSL. It's likely they'll
continue to optimize it and possibly also add the variants
they left out initially.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 29 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.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/archive%40mail-archive.com

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

[Victor Stinner]

Python 3.5 requires a 64 bit signed integer to build. Search for _PyTime
type in pytime.h ;-)
___
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/archive%40mail-archive.com