[Python-Dev] [RELEASE] Python 3.9.7 and 3.8.12 are now available

[Łukasz Langa]

Python 3.9.7

Get it here: https://www.python.org/downloads/release/python-397/ 

Python 3.9.7 is the newest major stable release of the Python programming 
language, and it contains many new features and optimizations. There’s been 187 
commits since 3.9.6 which is a similar amount compared to 3.8 at the same stage 
of the release cycle. See the change log 
 for details.

On macOS, we encourage you to use the universal2 binary installer variant 
whenever possible. The legacy 10.9+ Intel-only variant will not be provided for 
Python 3.10 and the universal2 variant will become the default download for 
3.9.8. You may need to upgrade third-party components, like pip, to later 
versions. You may experience differences in behavior in IDLE and other Tk-based 
applications due to using the newer version of Tk. As always, if you encounter 
problems when using this installer variant, please check 
https://bugs.python.org  for existing reports and for 
opening new issues.

The next Python 3.9 maintenance release will be 3.9.8, currently scheduled for 
2021-11-01.

 
The
 Second Security-Only Release of Python 3.8

Get it here: https://www.python.org/downloads/release/python-3812/ 

Security content in this release contains four fixes. There are also four 
additional fixes for bugs that might have lead to denial-of-service attacks. 
Finally, while we’re not providing binary installers anymore, for those users 
who produce installers, we upgraded the OpenSSL version used to 1.1.1l. Take a 
look at the change log 
 for details.

According to the release calendar specified in PEP 569 
, Python 3.8 is now in “security 
fixes only” stage of its life cycle: 3.8 branch only accepts security fixes and 
releases of those are made irregularly in source-only form until October 2024. 
Python 3.8 isn’t receiving regular bug fixes anymore, and binary installers are 
no longer provided for it. Python 3.8.10 was the last full bugfix release of 
Python 3.8 with binary installers.

 
Security
 releases of 3.7.12 and 3.6.15

Those aren’t ready just yet but are soon to follow.

Similarly to 3.8, Python 3.7 and 3.6 are now in “security fixes only” stage of 
their life cycle. Python 3.7 will be providing source archives until June 2023 
while Python 3.6 ends its life in December 2021.

 
We
 hope you enjoy the new releases

Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv 


signature.asc
Description: Message signed with OpenPGP
___
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/RMUOGC725MAGHTLQXS6254PJQ7X3GTMK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

[Brett Cannon]

On Sun, Aug 29, 2021 at 2:01 PM Serhiy Storchaka 
wrote:

> 29.08.21 23:16, Brett Cannon пише:
> > If you look at
> >
> https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea552c/Python/ceval.c#L2409-L2451
> > <
> https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea552c/Python/ceval.c#L2409-L2451
> >
> > you will see that `async for` requires that the iterator returned from
> > `__aiter__` define `__anext__`. But if you look at aiter() which uses
> > PyObject_GetAiter() from
> >
> https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2741-L2759
> > <
> https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2741-L2759
> >
> > and PyAiter_Check() from
> >
> https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2769-L2778
> > <
> https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66ffd57/Objects/abstract.c#L2769-L2778
> >
> > you will notice that aiter() requires `__anext__` *and* `__aiter__` on
> > the async iterator that gets returned from __aiter__.
> >
> > Now the docs for aiter() at
> > https://docs.python.org/3.10/library/functions.html#aiter
> >  points out
> > that the async iterator is expected to define both methods as does the
> > glossary definition for "asynchronous iterator"
> > (https://docs.python.org/3.8/glossary.html#term-asynchronous-iterator
> > ).
> >
> > So my question is whether the discrepancy between what `async for`
> > expects and what `aiter()` expects on purpose?
> > https://bugs.python.org/issue31861 
> > was the issue for creating aiter() and I didn't notice a discussion of
> > this difference. The key reason I'm asking is this does cause a
> > deviation compared to the relationship between `for` and `iter()` (which
> > does not require `__iter__` to be defined on the iterator, although
> > collections.abc.Iterator does). It also makes the glossary definition
> > being linked from
> >
> https://docs.python.org/3.10/reference/compound_stmts.html#the-async-for-statement
> > <
> https://docs.python.org/3.10/reference/compound_stmts.html#the-async-for-statement
> >
> > incorrect.
>
> PyIter_Check() only checks existence of __next__, not __iter__ (perhaps
> for performance reasons).
>

Or maybe no one thought to require __iter__ for iterators?


>
> I just ported changes from PyPy in SQLite tests
> (https://github.com/python/cpython/pull/28021) because a test class with
> __next__ but without __iter__ passed tests on CPython but failed on PyPy.
>

I'm going to wait to hear from anyone who may have been involved with
implementing aiter() and `async for` before proposing various ways to align
them with iter() and `for`.
___
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/KFI4DBTF33Q6HYFCBSYWGOTGRWY5YGHP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is anyone relying on new-bugs-announce/python-bugs-list/bugs.python.org summaries

[Victor Stinner]

Hi Ammar,

On Tue, Aug 24, 2021 at 12:17 AM Ammar Askar  wrote:
> 1. Weekly summary emails with bug counts and issues from the week,
> example: 
> https://mail.python.org/archives/list/python-dev@python.org/thread/JRFJ4QH7TR35HFRQWOYPPCGOYRFAXK24/

These emails annoy me. I learnt to mark them as read, as soon as I receive them.

I prefer to pick my favourite bugs directly at bugs.python.org and
then follow email notifications. Well, I'm already getting too many
notifications in general :-)

> 2. Emails sent to the new-bugs-announce and python-bugs-list for new
> issues and comments to existing issues.

I don't know these lists.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/OWZMAX3MZPJDCJ4L6KSWQK2V4EUHYLCR/
Code of Conduct: http://python.org/psf/codeofconduct/