[Python-Dev] [RELEASE] Python 3.8.3 is now available

[Łukasz Langa]

On behalf of the entire Python development community, and the currently serving 
Python release team in particular, I’m pleased to announce the release of 
Python 3.8.3, the third maintenance release of Python 3.8. You can find it here:

https://www.python.org/downloads/release/python-383/ 


It contains two months worth of bug fixes. Detailed information about all 
changes made in 3.8.3 can be found in its change log 
.
 Note that compared to 3.8.2, version 3.8.3 also contains the changes 
introduced in 3.8.3rc1.

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. See the “What’s New in Python 
3.8 ” document for more 
information about features included in the 3.8 series.

Maintenance releases for the 3.8 series will continue at regular bi-monthly 
intervals, with 3.8.4 planned for mid-July 2020.
One more thing

Unless blocked on any critical issue, Monday May 18th will be the release date 
of Python 3.9.0 beta 1. It’s a special release for us because this is when we 
lock the feature set for Python 3.9. If you can help testing the current 
available alpha release, that would be very helpful:

https://www.python.org/downloads/release/python-390a6/ 

We hope you enjoy the new Python release!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

https://www.python.org/psf/ 


Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv ___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6HMMY7U7X6ZDNGNSITN5IQZNEV6ND2F6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Antoine Pitrou]

On Wed, 13 May 2020 19:27:57 -0700
Ethan Furman  wrote:
> On 05/13/2020 06:04 AM, Antoine Pitrou wrote:
> > On Tue, 12 May 2020 11:36:38 -0700
> > Ethan Furman wrote:  
> >>
> >> Also, if a flag is used, won't that slow down every call to zip even when 
> >> the flag is False?  
> > 
> > Why would it?  Is that based on a rational analysis of how argument
> > parsing works?  
> 
> Not the call itself, but the running of zip.  Absent some clever programming 
> it seems to me that there are two choices if we have a flag:
> 
> - have two independent branches (basically `zip` and a `zip_strict` functions 
> inside `zip` itself) and have the flag select the branch; or
> 
> - have one branch which has extra logic that checks for at least one 
> StopIteration and at least one item in each iteration to see if it should 
> raise.

And how much do you think that costs, compared to the overall cost of
running the entire zip() function, including consumption of yielded
results by the calling frame?


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LDUDSLWQDZNNMSRKKNMOEC7NSVTUEKCC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Ethan Furman]

On 05/14/2020 05:43 AM, Antoine Pitrou wrote:

On Wed, 13 May 2020 19:27:57 -0700
Ethan Furman  wrote:

On 05/13/2020 06:04 AM, Antoine Pitrou wrote:

On Tue, 12 May 2020 11:36:38 -0700
Ethan Furman wrote:


Also, if a flag is used, won't that slow down every call to zip even when the 
flag is False?


Why would it?  Is that based on a rational analysis of how argument
parsing works?


Not the call itself, but the running of zip.  Absent some clever programming it 
seems to me that there are two choices if we have a flag:

- have two independent branches (basically `zip` and a `zip_strict` functions 
inside `zip` itself) and have the flag select the branch; or

- have one branch which has extra logic that checks for at least one 
StopIteration and at least one item in each iteration to see if it should raise.


And how much do you think that costs, compared to the overall cost of
running the entire zip() function, including consumption of yielded
results by the calling frame?


I don't know.  I saw zip being used in _pydecimal so I asked the question.

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QG6RTDYP7J6SP37AZGLYEYNQILCGSWCJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Brandt Bucher]

Ethan Furman wrote:
> So half of your examples are actually counter-examples.

I claimed to have found "dozens of other call sites in Python's standard 
library and tooling where it would be appropriate to enable this new feature". 
You asked for references, and I provided two dozen cases of zipping what must 
be equal length iterables.

I said they were "appropriate", not "needed" or even "recommended". These are 
call sites where unequal-length iterables, if encountered, would be an error 
that I would hope wouldn't pass silently. Besides, I don't think it's beyond 
the realm of imagination for a future refactoring of several of the "Mismatch 
cannot happen." cases to introduce a bug of this kind.

> Did you vet them, or just pick matches against `zip(`?

Of course. I spent hours vetting them, to the point of researching the GNU tar 
extended sparse header and Apple property list formats (and trying to figure 
out what the hell was happening in `os._fwalk`) just to make sure my 
understanding was correct.

Ethan Furman wrote:
> Not the call itself, but the running of zip.  Absent some clever programming 
> it seems to me that there are two choices if we have a flag:

I wouldn't call my implementation "clever", but it differs from both of these 
options.  We only need to check if we're strict when an error occurs in one of 
our iterators, which is a situation the C code for `zip` already needs to 
explicitly handle with a branch. So this condition is only hit on the "last" 
`__next__` call, not on every single iteration.

As a reminder, the actual C implementation is linked in the PEP (there's no PR 
yet but branch reviews are welcome), though I'd prefer if the PEP discussion 
didn't get bogged down in those specifics.  The pure-Python implementation in 
the PEP is *very* close to it, but it uses different abstractions for some of 
the details regarding error handling and argument parsing.[0]

However, for those who are interested, there is no measurable performance 
regression (and no additional parsing overhead for no-keyword-argument calls). 
Parsing the keyword argument (if present) adds <0.2us of overhead at creation 
time on my machine. I went ahead and ran some rough PGO/LTO benchmarks:

Creation time:

```

$ ./python-master -m pyperf timeit 'zip()'
Mean +- std dev: 79.4 ns +- 4.3 ns 
$ ./python-zip-strict -m pyperf timeit 'zip()'
Mean +- std dev: 79.0 ns +- 1.9 ns
$ ./python-zip-strict -m pyperf timeit 'zip(strict=True)'
Mean +- std dev: 240 ns +- 8 ns

```

Creation time + iteration time:

```

$ ./python-master -m pyperf timeit -s 'r = range(10)' '[*zip(r, r)]'
Mean +- std dev: 577 ns +- 35 ns
$ ./python-zip-strict -m pyperf timeit -s 'r = range(10)' '[*zip(r, r)]'
Mean +- std dev: 565 ns +- 16 ns
$ ./python-zip-strict -m pyperf timeit -s 'r = range(10)' '[*zip(r, r, 
strict=True)]'
Mean +- std dev: 756 ns +- 27 ns

$ ./python-master -m pyperf timeit -s 'r = range(100)' '[*zip(r, r)]'
Mean +- std dev: 3.54 us +- 0.14 us
$ ./python-zip-strict -m pyperf timeit -s 'r = range(100)' '[*zip(r, r)]'
Mean +- std dev: 3.49 us +- 0.07 us
$ ./python-zip-strict -m pyperf timeit -s 'r = range(100)' '[*zip(r, r, 
strict=True)]'
Mean +- std dev: 3.73 us +- 0.13 us

$ ./python-master -m pyperf timeit -s 'r = range(1000)' '[*zip(r, r)]'
Mean +- std dev: 44.1 us +- 2.0 us
$ ./python-zip-strict -m pyperf timeit -s 'r = range(1000)' '[*zip(r, r)]'
Mean +- std dev: 45.2 us +- 2.0 us
$ ./python-zip-strict -m pyperf timeit -s 'r = range(1000)' '[*zip(r, r, 
strict=True)]'
Mean +- std dev: 45.2 us +- 1.4 us

```

Additionally, the size of a `zip` instance has not changed.  Pickles for 
non-strict `zip` instances are unchanged as well.

Brandt

[0] And zip's current tuple caching, which is *very* clever.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZVCBS2S7IRIEU346AAJUEVH45VNMVOKI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python Language Summit 2020 blog posts

[Mariatta]

The rest of Python Language Summit articles are now out:

Property-Based Testing for Python Builtins and the Standard Library, Zac
Hatfield-Dodds:
https://pyfound.blogspot.com/2020/05/property-based-testing-for-python.html

Core Workflow Updates, Mariatta Wijaya:
https://pyfound.blogspot.com/2020/05/core-workflow-updates-python-language.html

CPython on Mobile Platforms, Russell Keith-Magee:
https://pyfound.blogspot.com/2020/05/cpython-on-mobile-platforms.html

Lightning talks: (
https://pyfound.blogspot.com/2020/05/lightning-talks-part-2.html)
- Teaching Python with Errors by Zac Hatfield-Dodds
- State of Jython by Jim Baker
- Read the Docs features of interest by Eric Holscher

Enjoy!

On Fri, May 1, 2020 at 10:02 AM Mariatta  wrote:

> Few more lightning talks from Eric Holscher and Zac Hatfield-Dodds
>>
>>
> ... and Jim Baker
>
> 
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OUR2XU34GPQB2G7LAGPQFX7KVYHAW4AL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Ethan Furman]

On 05/14/2020 11:13 AM, Brandt Bucher wrote:


I claimed to have found "dozens of other call sites in Python's standard
 library and tooling where it would be appropriate to enable this new
 feature". You asked for references, and I provided two dozen cases of
 zipping what must be equal length iterables.

I said they were "appropriate", not "needed" or even "recommended". These
 are call sites where unequal-length iterables, if encountered, would be
 an error that I would hope wouldn't pass silently.


Very good point.


 Besides, I don't thinkit's beyond the realm of imagination for a future
 refactoring of severalof the "Mismatch cannot happen." cases to introduce
 a bug of this kind.


Which seems besides the point.  As you say, if the lengths are mismatched
then a bug has appeared and if the check is nearly free there's no reason
not to do it.


Ethan Furman wrote:

Did you vet them ...


Of course. I spent hours vetting them, to the point of researching the GNU
 tar extended sparse header and Apple property list formats (and trying to
 figure out what the hell was happening in `os._fwalk`) just to make sure
 my understanding was correct.


Glad I'm not the only one that didn't immediately get that os._fwalk code.


Ethan Furman wrote:

Not the call itself, but the running of zip.


I wouldn't call my implementation "clever", but it differs from both of
those options.  We only need to check if we're strict when an error occurs
 in one of our iterators, which is a situation the C code for `zip` already
 needs to explicitly handle with a branch. So this condition is only hit on
 the "last" `__next__` call, not on every single iteration.


Ah, so this is why the strict version may consume an extra element -- it has
to check if any remaining iterators have elements, while the non-strict version
can just quit as soon as any of the iterators are exhausted.

   >>> one = iter([1, 2])
   >>> six = iter([6, 7, 8])

   >>> zip(one, six)
   (stuff)

   >>> next(six)
   8

vs

   >>> zip_strict(one, six)
   (stuff)

   >>> next(six)
   (crickets)


I went ahead and ran some rough PGO/LTO benchmarks...


Can you do those with _pydecimal?  If performance were an issue anywhere I would
expect to see it with number crunching.

---

Paul Moore and Chris Angelico have made good arguments in favor of an itertools
addition which haven't been answered yet.

Regardless, I think you've made the point that /a/ solution is very desirable.
So the real debate is whether it should be a flag, a mode, or a separate 
function.

I am still

-1 on the flag.

--
~Ethan~
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KMCGAJV7QKTTKFYDNJVZ3HSW5NC3BXQL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Brandt Bucher]

Ethan Furman wrote:
> Can you do those with _pydecimal?  If performance were an issue anywhere I 
> would expect to see it with number crunching.

No difference, probably because those methods look like they spend most of 
their time doing string manipulation:

```

$ export PYPERFSETUP='from _pydecimal import Decimal; from random import 
getrandbits; l = Decimal(bin(getrandbits(28))[2:]); r = 
Decimal(bin(getrandbits(28))[2:])' 
$ export PYPERFRUN='l.logical_and(r); l.logical_or(r); l.logical_xor(r)'

$ ./python-master -m pyperf timeit -s "$PYPERFSETUP" "$PYPERFRUN"
Mean +- std dev: 53.4 us +- 2.8 us
$ ./python-zip-strict -m pyperf timeit -s "$PYPERFSETUP" "$PYPERFRUN"
Mean +- std dev: 53.8 us +- 2.5 us
$ ./python-zip-strict -m pyperf timeit -s "$PYPERFSETUP" "$PYPERFRUN"  # This 
time, with strict=True in each method.
Mean +- std dev: 53.6 us +- 3.0 us

```

I would encourage those who are still curious to pull the branch and experiment 
for themselves. Let's try to keep this a design discussion, since we've 
established that performance isn't a problem (and there is plenty of time for 
code review later).

> Paul Moore and Chris Angelico have made good arguments in favor of an 
> itertools addition which haven't been answered yet.

I don't consider their arguments particularly strong, but yeah, I was getting 
to those. I wanted to address your points first since you weren't part of the 
Ideas discussion!

Paul Moore wrote:
> ... so it's another beast because (among other reasons) it lives in a 
> separate namespace, and it should live in a separate namespace because it's 
> another beast? That's circular logic.

Sorry, that's on me for trying to respond to two questions with one answer 
right before bed. Strike the namespace argument, then. The rest stands.

> So importing zip_strict from itertools is an entirely reasonable way for 
> users to enable the check, then.

Still agreed. But I think they would be *better* served by the proposed keyword 
argument.

This whole sub-thread of discussion has left me very confused. Was anything 
unclear in the PEP's phrasing here? If so, I'd like to improve it. The original 
quote is: "The goal here is not just to provide a way to catch bugs, but to 
also make it easy (even tempting) for a user to enable the check whenever using 
`zip` at a call site with this property."

> It's very easy to suggest bad ways of using a feature. That doesn't make the 
> feature bad. You seem to be arguing that zip_strict is bad because people can 
> misuse it.

Well, I addressed this "irrelevant" point because right out of the gate people 
started suggesting that they want a separate function *because* it makes 
shadowing easy. Which brings me to my next quote:

Chris Angelico wrote:
> I am most in favour of the separate-functions option *because* it makes 
> shadowing easy. Not an anti-pattern at all.

I *really* hope this isn't how people use this (and I don't *think* it would be 
predominantly used this way), but at least it's clear to me now why you want it 
to be a separate function.

It would still be quite simple to follow this pattern, though, with 
`functools.partial` or a custom wrapper.

> Python is *deliberately* designed so that you can shadow things.

I wouldn't confuse "can" and "should" here. Python is deliberately designed to 
make *many* design patterns possible, good and bad.

> And considering that "from __future__ import print_function" is an 
> officially-sanctioned way to cause a semantic change to print, I don't think 
> it's really that strong an argument.

Well that's a parser directive that is just there for 2/3 compatibility (I'm 
pretty sure - I've never used Python 2). I see it as very, very different from 
my `from pprint import pprint as print` headache that was quoted two levels up.

Brandt
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/67O5FJA5MB26WWAC7VV5IUQMEKMLCNYK/
Code of Conduct: http://python.org/psf/codeofconduct/