[RELEASE] The second Python 3.11 beta (3.11.0b2) is available
Does anyone want bug fixes? Because we have 164 new commits fixing different things, from code to documentation. If you have reported some issue after 3.11.0b1, you should check if is fixed and if not, make sure you tell us so we can take a look. We still have two more betas to go so help us to make sure we don't miss anything so everything is ready for the final release!! https://www.python.org/downloads/release/python-3110b2/ ## This is a beta preview of Python 3.11 Python 3.11 is still in development. 3.11.0b2 is the second of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We **strongly encourage** maintainers of third-party Python projects to **test with 3.11** during the beta phase and report issues found to [the Python bug tracker](https://github.com/python/cpython/issues) as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Monday, 2021-08-02). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after 3.11.0rc1, the first release candidate. To achieve that, it will be **extremely important** to get as much exposure for 3.11 as possible during the beta phase. Please keep in mind that this is a preview release and its use is **not** recommended for production environments. # Major new features of the 3.11 series, compared to 3.10 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* * [PEP 673](https://www.python.org/dev/peps/pep-0673/) -- Self Type * [PEP 646](https://www.python.org/dev/peps/pep-0646/)-- Variadic Generics * [PEP 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support for Parsing TOML in the Standard Library * [PEP 675](https://www.python.org/dev/peps/pep-0675/)-- Arbitrary Literal String Type * [PEP 655](https://www.python.org/dev/peps/pep-0655/)-- Marking individual TypedDict items as required or potentially-missing * [PEP 681](https://www.python.org/dev/peps/pep-0681/)-- Data Class Transforms * [bpo-46752](https://bugs.python.org/issue46752)-- Introduce task groups to asyncio * [bpo-433030](https://github.com/python/cpython/issues/34627/) -- Atomic grouping ((?>...)) and possessive quantifiers (`*+, ++, ?+, {m,n}+`) are now supported in regular expressions. * The [Faster Cpython Project](https://github.com/faster-cpython/) is already yielding some exciting results. Python 3.11 is up to 10-60% faster than Python 3.10. On average, we measured a 1.22x speedup on the standard benchmark suite. See [Faster CPython]( https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython) for details. * <small>(Hey, **fellow core developer,** if a feature you find important is missing from this list, [let Pablo know](mailto:pablogsal@python.org ).)</small> The next pre-release of Python 3.11 will be 3.11.0b3, currently scheduled for Thursday, 2022-06-16. # 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 The Planck time is the time required for light to travel a distance of 1 Planck length in a vacuum, which is a time interval of approximately `5.39*10^(−44)` s. No current physical theory can describe timescales shorter than the Planck time, such as the earliest events after the Big Bang, and it is conjectured that the structure of time breaks down on intervals comparable to the Planck time. While there is currently no known way to measure time intervals on the scale of the Planck time, researchers in 2020 found that the accuracy of an atomic clock is constrained by quantum effects on the order of the Planck time, and for the most precise atomic clocks thus far they calculated that such effects have been ruled out to around `10^−33` s, or 10 orders of magnitude above the Planck scale. # We hope you enjoy the 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. https://www.python.org/psf/ Regards from sunny London, Pablo Galindo Salgado
Hi, Le 31/05/2022 à 15:31, Pablo Galindo Salgado a écrit :
We **strongly encourage** maintainers of third-party Python projects to **test with 3.11** during the beta phase and report issues found to [the Python bug tracker](https://github.com/python/cpython/issues) as soon as possible.
I just tried doing that on the project I help maintaining (Pygments), but it turns out that it's a bit hard, presumably for many projects too, due to https://github.com/pytest-dev/pytest/issues/10008 which prevents pytest from running with 3.11.0b2. The fix for this issue is on the way (thanks!), but it has missed this release. Given pytest's popularity, this means 3.11.0b2 is sadly likely not to get as much testing exposure as wished ... Thus I wonder, would it be reasonable to exceptionally do another release shortly after this fix lands? Best, Jean PS: I tried to post this reply in Discourse, but apparently I'm not allowed to post in the category of the release announcement.
You may be able to work around this issue by preventing pytest to rewrite the assert statements by adding `--assert=plain` to the command line invocation until we have beta 3 next month. On Tue, 31 May 2022 at 23:57, Jean Abou Samra <jean@abou-samra.fr> wrote:
Hi,
Le 31/05/2022 à 15:31, Pablo Galindo Salgado a écrit :
We **strongly encourage** maintainers of third-party Python projects to **test with 3.11** during the beta phase and report issues found to [the Python bug tracker](https://github.com/python/cpython/issues) as soon as possible.
I just tried doing that on the project I help maintaining (Pygments), but it turns out that it's a bit hard, presumably for many projects too, due to
https://github.com/pytest-dev/pytest/issues/10008
which prevents pytest from running with 3.11.0b2.
The fix for this issue is on the way (thanks!), but it has missed this release. Given pytest's popularity, this means 3.11.0b2 is sadly likely not to get as much testing exposure as wished ...
Thus I wonder, would it be reasonable to exceptionally do another release shortly after this fix lands?
Best, Jean
PS: I tried to post this reply in Discourse, but apparently I'm not allowed to post in the category of the release announcement.
Le 01/06/2022 à 00:02, Pablo Galindo Salgado a écrit :
You may be able to work around this issue by preventing pytest to rewrite the assert statements by adding `--assert=plain` to the command line invocation until we have beta 3 next month.
Thank you! That did the trick. Worth mentioning in those release announcements that are editable, perhaps. Best, Jean
I have added a small note in the release announcements. Thanks for raising this with us! On Wed, 1 Jun 2022 at 00:13, Jean Abou Samra <jean@abou-samra.fr> wrote:
Le 01/06/2022 à 00:02, Pablo Galindo Salgado a écrit :
You may be able to work around this issue by preventing pytest to rewrite the assert statements by adding `--assert=plain` to the command line invocation until we have beta 3 next month.
Thank you! That did the trick. Worth mentioning in those release announcements that are editable, perhaps.
Best, Jean
On 01. 06. 22 0:02, Pablo Galindo Salgado wrote:
You may be able to work around this issue by preventing pytest to rewrite the assert statements by adding `--assert=plain` to the command line invocation until we have beta 3 next month.
That's possibly dozens---if not hundreds---of CI setups that would require a temporary hack in order to be able to continue testing with Python 3.11. It's wonderful that they can and many already do that now. Wouldn't it be more practical to bite the bullet and release b3 immediately with this fix? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
Wouldn't it be more practical to bite the bullet and release b3 immediately with this fix?
I sympathize with the sentiment and I am sorry that this is not practical but I am not fully convinced about the balance. Beta 3 is in one month and spinning an entire release is a multi-hour process for at least 3 people. I will discuss this with the release team but is unlikely. For testing at fedora, you can temporarily patch beta2 and include this commit: https://github.com/python/cpython/commit/b425d887aa51c8e7900b08cb8df457f450f... On Wed, 1 Jun 2022 at 00:19, Miro Hrončok <mhroncok@redhat.com> wrote:
On 01. 06. 22 0:02, Pablo Galindo Salgado wrote:
You may be able to work around this issue by preventing pytest to rewrite the assert statements by adding `--assert=plain` to the command line invocation until we have beta 3 next month.
That's possibly dozens---if not hundreds---of CI setups that would require a temporary hack in order to be able to continue testing with Python 3.11. It's wonderful that they can and many already do that now. Wouldn't it be more practical to bite the bullet and release b3 immediately with this fix?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
Just for the heads up: I have sent an email to the release team and we are considering the proposal. Thanks for raising this with us. On Tue, 31 May 2022 at 23:39, Pablo Galindo Salgado <pablogsal@gmail.com> wrote:
Wouldn't it be more practical to bite the bullet and release b3 immediately with this fix?
I sympathize with the sentiment and I am sorry that this is not practical but I am not fully convinced about the balance. Beta 3 is in one month and spinning an entire release is a multi-hour process for at least 3 people. I will discuss this with the release team but is unlikely. For testing at fedora, you can temporarily patch beta2 and include this commit:
https://github.com/python/cpython/commit/b425d887aa51c8e7900b08cb8df457f450f...
On Wed, 1 Jun 2022 at 00:19, Miro Hrončok <mhroncok@redhat.com> wrote:
On 01. 06. 22 0:02, Pablo Galindo Salgado wrote:
You may be able to work around this issue by preventing pytest to rewrite the assert statements by adding `--assert=plain` to the command line invocation until we have beta 3 next month.
That's possibly dozens---if not hundreds---of CI setups that would require a temporary hack in order to be able to continue testing with Python 3.11. It's wonderful that they can and many already do that now. Wouldn't it be more practical to bite the bullet and release b3 immediately with this fix?
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On 01. 06. 22 0:39, Pablo Galindo Salgado wrote:
Wouldn't it be more practical to bite the bullet and release b3 immediately with this fix?
I sympathize with the sentiment and I am sorry that this is not practical but I am not fully convinced about the balance. Beta 3 is in one month and spinning an entire release is a multi-hour process for at least 3 people. I will discuss this with the release team but is unlikely.
Understood. It's always a balance.
For testing at fedora, you can temporarily patch beta2 and include this commit:
Thanks. We already do that, my comment was motivated by the majority of upstream CI which do not use Fedora's Python 3.11 (yet?).
Just for the heads up: I have sent an email to the release team and we are considering the proposal. Thanks for raising this with us.
Awesome, thanks again. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
Update: we have decided to release Python 3.11.0b3. Let's hope this one is free of the curse :) On Wed, 1 Jun 2022 at 07:38, Miro Hrončok <mhroncok@redhat.com> wrote:
Wouldn't it be more practical to bite the bullet and release b3 immediately with this fix?
I sympathize with the sentiment and I am sorry that
On 01. 06. 22 0:39, Pablo Galindo Salgado wrote: this is not practical but I
am not fully convinced about the balance. Beta 3 is in one month and spinning an entire release is a multi-hour process for at least 3 people. I will discuss this with the release team but is unlikely.
Understood. It's always a balance.
For testing at fedora, you can temporarily patch beta2 and include this commit:
Thanks. We already do that, my comment was motivated by the majority of upstream CI which do not use Fedora's Python 3.11 (yet?).
Just for the heads up: I have sent an email to the release team and we are considering the proposal. Thanks for raising this with us.
Awesome, thanks again.
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On 01/06/2022 16:58, Pablo Galindo Salgado wrote:
Update: we have decided to release Python 3.11.0b3. Let's hope this one is free of the curse :)
........ Hi I hade a couple of failures related to the compile failure for ASTs with wrongly ranged start-end attributes. After spending a while sorting those I hope that b3 will still work for those case. Will the reasonable range requirement eventually be made mandatory? It does seem like a good idea. Will there be an extra beta? -- Robin Becker
Hi Robin, The correct range requirements are mandatory from beta 2. There will be 2 more betas after beta 3: beta4 and beta5. Please, check out the release announcement for beta3. Cheers, Pablo Galindo Salgado On Fri, 3 Jun 2022, 09:56 Robin Becker, <robin@reportlab.com> wrote:
On 01/06/2022 16:58, Pablo Galindo Salgado wrote:
Update: we have decided to release Python 3.11.0b3. Let's hope this one is free of the curse :)
........
Hi I hade a couple of failures related to the compile failure for ASTs with wrongly ranged start-end attributes. After spending a while sorting those I hope that b3 will still work for those case.
Will the reasonable range requirement eventually be made mandatory? It does seem like a good idea.
Will there be an extra beta?
-- Robin Becker
participants (4)
-
Jean Abou Samra -
Miro Hrončok -
Pablo Galindo Salgado -
Robin Becker