[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

[Petr Viktorin]

On 07. 12. 21 20:58, Guido van Rossum wrote:
On Tue, Dec 7, 2021 at 11:02 AM Christian Heimes > wrote:


On 07/12/2021 19.28, Guido van Rossum wrote:
 > I assume it would be insensitive to ask whether we could just get
rid of
 > the stable ABI altogether and focus on the limited API? Just tell
 > everyone they have to rebuild binary wheels for every Python feature
 > release. Presumably the deprecation of the stable ABI itself would
 > require a two-release waiting period. But maybe it would be worth
it,
 > given how subtle it is to do the historical research about even a
single
 > function.

The stable ABI is useful for Python packages that ship binary wheels.

Take PyCA cryptography [1] as an example. Alex and Paul already build,
upload, and ship 12 abi3 wheels for each release and combinations of
CPU
arch, platform, and libc ABI. Without a stable ABI they would have to
create a total of 60 binary abi3 wheels for Python 3.6 to 3.10. The
number will only increase over time. Python 3.6 is very common on
LTS/Enterprise Linux distros.


Thanks, that's a very useful example.

If the current stable ABI makes performance improvements too complex
then we should consider to define a new stable ABI with less symbols.


But then we will run into backwards compatibility concerns. Suppose we 
want to delete *one* functions from the stable ABI. How many releases do 
we have to wait before we can actually delete (as opposed to just 
deprecate) it? It sounds like you're saying it would take 5 releases, 
i.e. if we deprecate it in 3.11, we can delete it in 3.16. It would 
probably be easier to just not bother with the deprecation.


That really depends on what function we'd want to remove. There are 
usually alternatives to deleting things, but the options depend on the 
function. If we run out of other options we can make the function always 
fail or make it leak memory.
And the regular backwards compatibility policy gives us 2 years to 
figure something out :)



It is possible that we'll need a new stable ABI for nogil, though, since 
refcounting is one of the few areas where even the stable ABI uses 
direct struct access rather than functions.

___
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/WN7TBSV6LM24X6CIEQQDG63OYPIR5ZLU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[Petr Viktorin]

On 08. 12. 21 1:47, Victor Stinner wrote:

For me, HPy is the only valid stable API and stable ABI in the long
term which is efficient on any Python implementation. Its design is
very different than the C API: HPy avoids all C API design mistakes,
it doesn't leak any implementation detail.

HPy can already be used today on CPython, even if it's not directly
provided by CPython.

Providing HPy as a first-class citizen in CPython, as already done in
PyPy, would be great to promote HPy! However, HPy evolves quickly and
so needs to be released more frequently than CPython. At least, we
could promote it more in the C API documentation, as we already
promote Cython.

Promoting the HPy usage doesn't solve any issue listed in PEP 620, 670
and 674 since CPython still has to continue supporting the C API. We
will only be fully free to make any change in Python internals without
having to care about breaking the C API once the *LAST* C extensions
using the C API will disappear... Look at Python 2.7 which is still
used in 2021. I bet that C extensions using the C API are not doing to
disappear soon.

For me, the question is:

=> Is it ok to no longer be able to make any change in Python
internals because of the public C API?

The sub-question is:

=> Is it ok to have a slow deprecation process and wait 5 to 10 years
until it will be possible again to evolve the Python internals?


No, they should be evolved when they *need* to be evolved.
This PEP calls for breaking things because they *might* need evolving in 
the future, but doesn't presemt any immediate benefit. In that case, I 
think it's better document that we don't like some usage, but only do 
the removals when they're helpful.


Especially in cases where there can't be a proper deprecation period.
___
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/WIEC7X4CTPL7PN7EIOJJJWCJJ5ZBYH7M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[Petr Viktorin]

On 07. 12. 21 17:54, Joao S. O. Bueno wrote:

Sorry for stepping in - but I am seeing too many arguments in favour
of the rules because "they are the rules", and just Victor arguing with
what is met in the "real world".


OTOH, coming up with rules and then blatantly ignoring them is silly at 
best.


If the rules are bad, they should definitely be changed. And if a case 
is exceptional enough, we should make an exception -- but to make an 
exception we need a very good understanding of why the rules are the way 
they are (and in this case. I don't think any single person has the 
proper understanding).



One of the roles the backwards compatibility policy serves is a promise 
to our users. They can expect to not run into problems if they only 
upgrade to every second Python version and fix deprecation warnings 
(except for "extreme situations such as dangerously broken or insecure 
features or features no one could reasonably be depending on").

That is, IMO, a pretty good reason to consider sticking to the rules.
___
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/NXOKMGCN3TOU7CA2YX3ZNRZMCPNJ2VUF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[matti . picus]

Victor Stinner wrote:
> First, PyPy tried to only implement a subset of the C API and promote
> cffi for incompatible C extensions. This approach failed.

Just to be clear: I don't think any of the PyPy devs assumed the huge Python 
c-extension ecosystem would suddenly run to adopt CFFI, so calling our effort 
to emulate the C-API a consequence of any failure is a bit of an exaggeration.

> So PyPy decided to be as compatible as possible with CPython for the C
> API. Now PyPy basically supports the whole C API and doesn't want to
> drop support for the C extensions "abusing" the C API, like using
> macros as l-value.

I think it would be more accurate to say that PyPy, as a small project in the 
huge Python ecosystem, is trying to support any C-API used widely by the 
community. If there is a common PyPy voice (after all, we are also a project 
with many opinions),  we don't "not want to drop support" nor "want to drop 
support" for any commonly used C-API interfaces, rather we want to stay out of 
this argument and promote alternatives such as CFFI, cppyy, and HPy instead. 

> Victor

Matti
___
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/3HGX42QFURHCU6O6DOKBXLVTFIU6RDBO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

[Petr Viktorin]

On 07. 12. 21 19:28, Guido van Rossum wrote:
On Tue, Dec 7, 2021 at 12:58 AM Petr Viktorin > wrote:


On 06. 12. 21 21:50, Guido van Rossum wrote:

[...]

 > Also, it looks like Mark is proposing to *remove*
_PyObject_GC_Malloc
 > from stable_abi.txt in
https://github.com/python/cpython/pull/29879

 > > Is that allowed? If
it's
 > being used by a macro it means code using that macro will fail
unless
 > recompiled for 3.11.

Generally, that's not allowed. In this particular case, Victor's
analysis is right: if you trawl through the history from 3.2 on, you
can
see that you can't call _PyObject_GC_Malloc via macros in the limited
API. So yes, this one can be removed.


Okay, that's very subtle, so thanks for confirming.

I'll also note that removing things that are "allowed" to go is not
nice
to people who relied on PEP 384, which says that defining
Py_LIMITED_API
"will hide all definitions that are not part of the ABI" -- even though
that's incompatible with the part where it says "All functions starting
with _Py are not available to applications".


I don't actually really follow what you are trying to say here. Probably 
because I've never paid much attention to PEP 384. I guess the API is 
confusing because the "right" way to do it (having to define some symbol 
to *expose* extra stuff rather than to *hide* stuff) was not possible 
for backwards compatibility reasons. But the extra negative will forever 
make this confusing. Also, "All functions starting with _Py are not 
available" sounds like a clumsy way to say "No functions starting with 
_Py are available" (and you left out whether Py_LIMITED_API affects that 
availability, whether it was intended to affect it, whether it did in 
practice affect it in all cases, etc.


It's hard to say what PEP 384 was meant to say. My interpretation, PEP 
652, is hopefully more consistent. But someone who had a different 
interpretation of PEP 384 might feel that it broke some promise.



I assume it would be insensitive to ask whether we could just get rid of 
the stable ABI altogether and focus on the limited API? Just tell 
everyone they have to rebuild binary wheels for every Python feature 
release. Presumably the deprecation of the stable ABI itself would 
require a two-release waiting period. But maybe it would be worth it, 
given how subtle it is to do the historical research about even a single 
function.


A honest question wouldn't be insensitive. Thanks for asking!

The part where you don't need to rebuild extensions (not just wheels) is 
the main reason for both Stable ABI and the Limited API.
Without it, there might be some reduced API to focus on, but it wouldn't 
be this feature.

___
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/SBQHQ6DWSXMDVQCETVDMRLZ3CNG4OJUL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

[Paul Moore]

On Wed, 8 Dec 2021 at 12:42, Petr Viktorin  wrote:
> > I assume it would be insensitive to ask whether we could just get rid of
> > the stable ABI altogether and focus on the limited API? Just tell
> > everyone they have to rebuild binary wheels for every Python feature
> > release. Presumably the deprecation of the stable ABI itself would
> > require a two-release waiting period. But maybe it would be worth it,
> > given how subtle it is to do the historical research about even a single
> > function.
>
> A honest question wouldn't be insensitive. Thanks for asking!
>
> The part where you don't need to rebuild extensions (not just wheels) is
> the main reason for both Stable ABI and the Limited API.
> Without it, there might be some reduced API to focus on, but it wouldn't
> be this feature.

This I think is the critical point here. I don't follow the API/ABI
debate closely, but I do know that the number varieties of C extension
builds some projects have to make is a serious overhead. Being able to
target the stable ABI and say "this will work for all (essentially)
versions of CPython" is a huge benefit, as it reduces the number (and
hence the burden) significantly.

Not having to amend your source for each CPython release feels to me
like a subset of this, and loses a major advantage, so my personal
view is that the stable ABI is far more beneficial than the limited
API (the limited API is what you fall back to if you're unable to use
the stable ABI).

Paul
___
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/KCAIYXMKY7RZULJNG7BGM5OQ7RF5Z266/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[matti . picus]

On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum gu...@python.org wrote:

I wonder if there’s a role for HPy in this context? What if instead of
evolving the stable ABI and the limited API, instead we were to focus on
first-class support for HPy?

The hope with the HPy project is indeed to provide a C API that is close to the 
original API to make porting easy and have it perform as close to the existing 
API as possible. At the same time, HPy is sufficently removed to be a good “C 
extension API” (as opposed to a stable subset of the CPython implementation 
API) that does not leak implementation details. To ensure this latter property 
is why we try to develop everything in parallel for CPython, PyPy, and GraalVM 
Python.

On Wed, 8 Dec 2021 01:47:38 +0100 Victor Stinner vstin...@python.org wrote:

Providing HPy as a first-class citizen in CPython, as already done in
PyPy, would be great to promote HPy! However, HPy evolves quickly and
so needs to be released more frequently than CPython. At least, we
could promote it more in the C API documentation, as we already
promote Cython.

Indeed, at this point HPy is still evolving very fast. We are still solving
issues while migrating NumPy, have begun adding support for HPy to Cython,
and will start working on pybind11 soon. I believe by the time we have these
users of the existing C API working, HPy should be in a state where it is
generally useful and can be deemed stable enough that further development can 
follow a more stable process.

For me, HPy is the only valid stable API and stable ABI in the long
term which is efficient on any Python implementation. Its design is
very different than the C API: HPy avoids all C API design mistakes,
it doesn’t leak any implementation detail.

In the long run the HPy project would like to become a promoted API to
write Python C extensions.

Tim Felgentreff, posted by Matti Picus
(on behalf of the HPy team)
___
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/GBDS2W575VED2KQN6DIN7E5JCMNKNQJF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

[Eric Snow]

On Wed, Dec 8, 2021 at 2:23 AM Petr Viktorin  wrote:
> That really depends on what function we'd want to remove. There are
> usually alternatives to deleting things, but the options depend on the
> function. If we run out of other options we can make the function always
> fail or make it leak memory.
> And the regular backwards compatibility policy gives us 2 years to
> figure something out :)

What about the various symbols listed in Misc/stable_abi.txt that were
accidentally added to the limited API?  Can we move toward dropping
them from the stable ABI?

Most notably, there are quite a few functions listed there that are in
the stable ABI but no longer in the limited API.  This implies that
either they were already deprecated in the limited API (and removed)
or they were just removed.  At least in some cases they were moved to
header files in Include/cpython or Include/internal.  So I would not
expect extensions to be using them.  This subset of those symbols
seems entirely appropriate to remove from the stable ABI.  Is that
okay?  Do we even need to bother deprecating them?  What about just
the "private" ones?

For example, I went to change/remove _PyThreadState_Init() (internal
API declared in Include/internal/pycore_pystate.h) and found that it
is in the stable ABI but not the limited API.  It's highly unlikely
anyone is using it and plan on double-checking.  As far as I can tell,
the function was accidentally exposed in the limited API and stable
ABI and later removed from the limited API.

-eric
___
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/OJ65FPCJ2NVUFNZDXVNK5DU3R3JGLL3J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[Tim Felgentreff]

Hi,

On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum  wrote:
> I wonder if there's a role for HPy in this context? What if instead of
> evolving the stable ABI and the limited API, instead we were to focus on
> first-class support for HPy?

The hope with the HPy project is indeed to provide a C API that is close to the
original API to make porting easy and have it perform as close to the existing
API as possible. At the same time, HPy is sufficently removed to be a good "C
extension API" (as opposed to a stable subset of the CPython implementation API)
that does not leak implementation details. To ensure this latter property is why
we try to develop everything in parallel for CPython, PyPy, and GraalVM Python.

On Wed, 8 Dec 2021 01:47:38 +0100 Victor Stinner  wrote:
> Providing HPy as a first-class citizen in CPython, as already done in
> PyPy, would be great to promote HPy! However, HPy evolves quickly and
> so needs to be released more frequently than CPython. At least, we
> could promote it more in the C API documentation, as we already
> promote Cython.

Indeed, at this point HPy is still evolving very fast. We are still solving
issues while migrating NumPy, have begun adding support for HPy to Cython,
and will start working on pybind11 soon. I believe by the time we have these
users of the existing C API working, HPy should be in a state where it is
generally useful and can be deemed stable enough that further development can
follow a more stable process.

> For me, HPy is the only valid stable API and stable ABI in the long
> term which is efficient on any Python implementation. Its design is
> very different than the C API: HPy avoids all C API design mistakes,
> it doesn't leak any implementation detail.

In the long run the HPy project would like to become a promoted API to
write Python C extensions.

Tim Felgentreff
(on behalf of the HPy team)
___
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/2NFJC7UAVIQZ6BNV4NBTY3THI7OIJIMF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[Tim Felgentreff]

Hi,

On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum  wrote:
> I wonder if there's a role for HPy in this context? What if instead of
> evolving the stable ABI and the limited API, instead we were to focus on
> first-class support for HPy?

The hope with the HPy project is indeed to provide a C API that is close to the
original API to make porting easy and have it perform as close to the existing
API as possible. At the same time, HPy is sufficently removed to be a good "C
extension API" (as opposed to a stable subset of the CPython implementation API)
that does not leak implementation details. To ensure this latter property is why
we try to develop everything in parallel for CPython, PyPy, and GraalVM Python.

On Wed, 8 Dec 2021 01:47:38 +0100 Victor Stinner  wrote:
> Providing HPy as a first-class citizen in CPython, as already done in
> PyPy, would be great to promote HPy! However, HPy evolves quickly and
> so needs to be released more frequently than CPython. At least, we
> could promote it more in the C API documentation, as we already
> promote Cython.

Indeed, at this point HPy is still evolving very fast. We are still solving
issues while migrating NumPy, have begun adding support for HPy to Cython,
and will start working on pybind11 soon. I believe by the time we have these
users of the existing C API working, HPy should be in a state where it is
generally useful and can be deemed stable enough that further development can
follow a more stable process.

> For me, HPy is the only valid stable API and stable ABI in the long
> term which is efficient on any Python implementation. Its design is
> very different than the C API: HPy avoids all C API design mistakes,
> it doesn't leak any implementation detail.

In the long run the HPy project would like to become a promoted API to
write Python C extensions.


Tim Felgentreff
(on behalf of the HPy team)

___
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/BI276X4LW7T6XHTX46OEMF4GONOD5FWA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

[Tim Felgentreff]

I am sorry for the multi-post, it seems the first message I sent and which I 
thought got lost somewhere along the way was simply routed via pidgeon. I 
promise to wait for the message to arrive more patiently next time.

Tim


From: Tim Felgentreff 
Sent: Wednesday, 8 December 2021, 18:21
To: python-dev@python.org
Subject: [External] : [Python-Dev] Re: PEP 674: Disallow using macros as l-value

Hi,

On Tue, 7 Dec 2021 16:08:27 -0800 Guido van Rossum  wrote:
> I wonder if there's a role for HPy in this context? What if instead of
> evolving the stable ABI and the limited API, instead we were to focus on
> first-class support for HPy?

The hope with the HPy project is indeed to provide a C API that is close to the
original API to make porting easy and have it perform as close to the existing
API as possible. At the same time, HPy is sufficently removed to be a good "C
extension API" (as opposed to a stable subset of the CPython implementation API)
that does not leak implementation details. To ensure this latter property is why
we try to develop everything in parallel for CPython, PyPy, and GraalVM Python.

On Wed, 8 Dec 2021 01:47:38 +0100 Victor Stinner  wrote:
> Providing HPy as a first-class citizen in CPython, as already done in
> PyPy, would be great to promote HPy! However, HPy evolves quickly and
> so needs to be released more frequently than CPython. At least, we
> could promote it more in the C API documentation, as we already
> promote Cython.

Indeed, at this point HPy is still evolving very fast. We are still solving
issues while migrating NumPy, have begun adding support for HPy to Cython,
and will start working on pybind11 soon. I believe by the time we have these
users of the existing C API working, HPy should be in a state where it is
generally useful and can be deemed stable enough that further development can
follow a more stable process.

> For me, HPy is the only valid stable API and stable ABI in the long
> term which is efficient on any Python implementation. Its design is
> very different than the C API: HPy avoids all C API design mistakes,
> it doesn't leak any implementation detail.

In the long run the HPy project would like to become a promoted API to
write Python C extensions.

Tim Felgentreff
(on behalf of the HPy team)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://urldefense.com/v3/__https://mail.python.org/mailman3/lists/python-dev.python.org/__;!!ACWV5N9M2RV99hQ!aoUoshCDK0NCYcZl7KiFcC2WO7noi5LMeO6Fh_cwqn-y1PS8k_aqbBsSKvPRxq9nWh0S$
Message archived at 
https://urldefense.com/v3/__https://mail.python.org/archives/list/python-dev@python.org/message/2NFJC7UAVIQZ6BNV4NBTY3THI7OIJIMF/__;!!ACWV5N9M2RV99hQ!aoUoshCDK0NCYcZl7KiFcC2WO7noi5LMeO6Fh_cwqn-y1PS8k_aqbBsSKvPRxqoIdm36$
Code of Conduct: 
https://urldefense.com/v3/__http://python.org/psf/codeofconduct/__;!!ACWV5N9M2RV99hQ!aoUoshCDK0NCYcZl7KiFcC2WO7noi5LMeO6Fh_cwqn-y1PS8k_aqbBsSKvPRxhko9lh5$

___
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/QPWSVPSAGJF37ERPXFYMIREXPL4KJR2W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.11.0a3 is available

[Pablo Galindo Salgado]

You can tell that we are slowly getting closer to the first beta as the
number of release blockers that we need to fix on every release starts to
increase [image: :sweat_smile:] But we did it! Thanks to Steve Dower, Ned
Deily, Christian Heimes, Łukasz Langa and Mark Shannon that helped get
things ready for this release :)

Go get the new version here:

https://www.python.org/downloads/release/python-3110a3/

**This is an early developer preview of Python 3.11**

# Major new features of the 3.11 series, compared to 3.10

Python 3.11 is still in development.  This release, 3.11.0a3 is the third
of seven planned alpha releases.

Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.

During the alpha phase, features may be added up until the start of the
beta phase (2022-05-06) and, if necessary, may be modified or deleted up
until the release candidate phase (2022-08-01).  Please keep in mind that
this is a preview release and its use is **not** recommended for production
environments.

Many new features for Python 3.11 are still being planned and written.
Among the new major new features and changes so far:

* [PEP 657](https://www.python.org/dev/peps/pep-0657/) -- Include
Fine-Grained Error Locations in Tracebacks
* [PEP 654](https://www.python.org/dev/peps/pep-0654/) -- Exception Groups
and except*
* The [Faster Cpython Project](https://github.com/faster-cpython) is
already yielding some exciting results: this version of CPython 3.11 is
~12% faster on the geometric mean of the [PyPerformance benchmarks](
speed.python.org), compared to 3.10.0.
 * Hey, **fellow core developer,** if a feature you find important is
missing from this list, let me know.

The next pre-release of Python 3.11 will be 3.11.0a4, currently scheduled
for Monday, 2022-01-03.

# More resources

* [Online Documentation](https://docs.python.org/3.11/)
* [PEP 664](https://www.python.org/dev/peps/pep-0664/), 3.11 Release
Schedule
* Report bugs at [https://bugs.python.org](https://bugs.python.org).
* [Help fund Python and its community](/psf/donations/).

# And now for something completely different

Rayleigh scattering, named after the nineteenth-century British physicist
Lord Rayleigh is the predominantly elastic scattering of light or other
electromagnetic radiation by particles much smaller than the wavelength of
the radiation. For light frequencies well below the resonance frequency of
the scattering particle, the amount of scattering is inversely proportional
to the fourth power of the wavelength. Rayleigh scattering results from the
electric polarizability of the particles. The oscillating electric field of
a light wave acts on the charges within a particle, causing them to move at
the same frequency. The particle, therefore, becomes a small radiating
dipole whose radiation we see as scattered light. The particles may be
individual atoms or molecules; it can occur when light travels through
transparent solids and liquids but is most prominently seen in gases.

The strong wavelength dependence of the scattering means that shorter
(blue) wavelengths are scattered more strongly than longer (red)
wavelengths. This results in the indirect blue light coming from all
regions of the sky.

# We hope you enjoy those new releases!

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.

Your friendly release team,
Pablo Galindo @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
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/UJULODWK44IYR7HIITSBUQ75YC33FJUC/
Code of Conduct: http://python.org/psf/codeofconduct/