[RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available
I cannot believe I am writing this, but Python 3.11.b4 is finally available!! [image: :scream:] [image: :tada:] [image: :tada:] [image: :tada:] https://www.python.org/downloads/release/python-3110b4/ ##[image: :warning:][image: :warning:][image: :warning:] PLEASE HELP US TO TEST THIS RELEASE [image: :warning:][image: :warning:][image: :warning:] Due to the modified release schedule and the stability concerns regarding the past beta releases, please, please, please, please, help us to test Python 3.11 by testing this beta releases. * if you maintain a library or a third-party package. Test the beta releases! * If you have code that you maintain at work/research centre/classroom/whatever. Test the beta releases! * If you are a multi-million corporation that uses Python. Test the beta releases! * If you are a single-person company that uses Python. Test the beta releases! * If you have a bunch of Python scripts. Test the beta releases! * If you use Python for work, research, teaching or literally for anything. Test the beta releases! * If you ... In summary: no matter who you are or what you do. Test the beta releases! Is **very** important for us that we identify all possible things that may break your code **before** the final release is done and we can only do this if you help us by testing the beta releases and then report anything that doesn't work! ## Credit where credit is due [image: :pray:] Lots of thanks to Christian Heimes, Brandt Bucher, Irit Katriel, Mark Shannon, Dennis Sweeney, Kumar Aditya and other contributors (sorry if I am missing any names) that worked really hard against time to help me and the release team with the release blockers. They are all awesome and we and the Python community are very lucky to have them in the team [image: :heart:] ## What happens with the next betas? As stated in [my previous communication]( https://mail.python.org/archives/list/python-dev@python.org/thread/3JWVCSBPB...) we are in a special situation regarding beta releases. As the requirements to continue with the regular schedule are met, we are going to still target the final release of Monday, 2022-10-03. Python 3.11.0b5 was supposed to be released two days ago, so we are obviously delayed. As we are targeting the regular release schedule, I'm going to try to release 3.11.0b5 on Thursday, 2022-07-25. ## This is a beta preview of Python 3.11 Python 3.11 is still in development. 3.11.0b4 is the fourth of five 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 have no ABI changes after beta 5 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 Some of the new major new features and changes in Python 3.11 are: ## General changes * [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 680](https://www.python.org/dev/peps/pep-0680/)-- tomllib: Support for Parsing TOML in the Standard Library * [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. ## Typing and typing language changes * [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 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 <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.0b5, currently scheduled for Thursday, 2022-07-25. # 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 temperature is 1.416784×10**32 K. At this temperature, the wavelength of light emitted by thermal radiation reaches the Planck length. There are no known physical models able to describe temperatures greater than the Planck temperature and a quantum theory of gravity would be required to model the extreme energies attained. Hypothetically, a system in thermal equilibrium at the Planck temperature might contain Planck-scale black holes, constantly being formed from thermal radiation and decaying via Hawking evaporation; adding energy to such a system might decrease its temperature by creating larger black holes, whose Hawking temperature is lower. Rumours say the Planck temperature can be reached in some of the hottest parts of Spain in summer. # 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/ If you have any questions, please reach out to me or another member of the release team :) Your friendly release team, Ned Deily @nad https://discuss.python.org/u/nad Steve Dower @steve.dower https://discuss.python.org/u/steve.dower Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal
BSD-style checksum format hashes for the release artefacts: SHA256 (python-3.11.0b4-embed-arm64.zip) = 272c6bb4948c597f6578f64c2b15a70466c5dfb49f9b84dba57a84e59e7bd4ef SHA256 (python-3.11.0b4-amd64.exe) = a3514b0401e6a85416f3e080586c86ccd9e2e62c8a54b9119d9e6415e3cadb62 SHA256 (python-3.11.0b4-macos11.pkg) = 860647775d4e6cd1a8d71412233df5dbe3aa2886fc16d82a59ab2f625464f2d7 SHA256 (python-3.11.0b4-embed-win32.zip) = 36b81da7986f8d59be61adb452681dbd3257ebb90bd89092b2fbbd9356e06425 SHA256 (python-3.11.0b4-arm64.exe) = ad0d1429682ba1edc0c0cf87f68a3d1319b887b715da70a91db41d02be4997a4 SHA256 (python-3.11.0b4-embed-amd64.zip) = 66e6bb44c36da36ecc1de64efdb92f52ba3a19221dba2a89e22e39f715bd205b SHA256 (Python-3.11.0b4.tar.xz) = 1d93b611607903e080417c1a9567f5fbbf5124cc5c86f4afbba1c8fd34c5f6fb SHA256 (python-3.11.0b4.exe) = 6febc152711840337f53e2fd5dc12bb2b1314766f591129282fd372c855fa877 SHA256 (Python-3.11.0b4.tgz) = 257e753db2294794fa8dec072c228f3f53fd541a303de9418854b3c2512ccbec
Does anyone have the ear of someone at github? It would make testing this beta much easier if they would merge the PR to allow installing 3.11.b4 in github actions: https://github.com/actions/python-versions/pull/177 Samuel Also the GH bot is using DD/MM/YYYY date format :-( whyyyyyy? -- Samuel Colvin 07801160713 On Mon, 11 Jul 2022 at 20:32, Pablo Galindo Salgado <pablogsal@gmail.com> wrote:
Also the GH bot is using DD/MM/YYYY date format :-( whyyyyyy?
Because github is international, and everyone but the US seems to agree that ``` /\ / \ / \ / day \ /________\ / \ / month \ /______________\ / \ / year \ /____________________\ ``` is preferable to ``` __________ / \ / month \ /______________\ /\ / \ / \ / day \ ___/________\___ / \ / year \ /____________________\ ```
On 13/07/2022 12:12, h.vetinari@gmx.com wrote:
I much prefer YYYY-MM-DD (or YYYY.MM.DD) because: 1. It's consistent with HH:MM:SS and other instances where there are multiple units (they go from largest to smallest). 2. It's easier to sort them. 3. It removes the confusion over whether it's DD/MM/YYYY or MM/DD/YYYY.
4. It implements ISO 8601 (which exists for a reason): https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates On 7/14/2022 6:25 PM, MRAB wrote:
Alan G. Isaac writes:
4. It implements ISO 8601 (which exists for a reason): https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates
Yes!!! "Standardization is my Valentine!" :-D -- RIP WotR Bombshell
Since a few people have reacted to my PS comment: I suffered (committed) a very confusing typo; the github bot refers to "07/13/2022" (e.g. MM/DD/YYYY) which drew my ire, I then confusingly referenced a different format in my comment. Overall, I agree we should be using ISO8601 for exactly this reason (at least for dates, for datetimes ISO8601 gets pretty wacky <https://ijmacd.github.io/rfc3339-iso8601/>) Samuel -- Samuel Colvin 07801160713 On Fri, 15 Jul 2022 at 05:39, Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:
Samuel Colvin writes:
I have never had a use for anything but yyyy-mm-ddThh:mm:ss (and very occasionally yyyy-mm-ddZhh:mm:ss for international coordination). What's wacky about that? It's not terribly human-readable, but for humans you can substitute a space for T (Z) and append a timezone or offset if you want to disambiguate. Sure, there is lots of optional syntax in ISO 8601, but when does one need the wacky stuff in a release announcement? Steve
You have: Report bugs at [https://bugs.python.org%5D(https://bugs.python.org). Why not change to https://github.com/python/cpython/issues
BSD-style checksum format hashes for the release artefacts: SHA256 (python-3.11.0b4-embed-arm64.zip) = 272c6bb4948c597f6578f64c2b15a70466c5dfb49f9b84dba57a84e59e7bd4ef SHA256 (python-3.11.0b4-amd64.exe) = a3514b0401e6a85416f3e080586c86ccd9e2e62c8a54b9119d9e6415e3cadb62 SHA256 (python-3.11.0b4-macos11.pkg) = 860647775d4e6cd1a8d71412233df5dbe3aa2886fc16d82a59ab2f625464f2d7 SHA256 (python-3.11.0b4-embed-win32.zip) = 36b81da7986f8d59be61adb452681dbd3257ebb90bd89092b2fbbd9356e06425 SHA256 (python-3.11.0b4-arm64.exe) = ad0d1429682ba1edc0c0cf87f68a3d1319b887b715da70a91db41d02be4997a4 SHA256 (python-3.11.0b4-embed-amd64.zip) = 66e6bb44c36da36ecc1de64efdb92f52ba3a19221dba2a89e22e39f715bd205b SHA256 (Python-3.11.0b4.tar.xz) = 1d93b611607903e080417c1a9567f5fbbf5124cc5c86f4afbba1c8fd34c5f6fb SHA256 (python-3.11.0b4.exe) = 6febc152711840337f53e2fd5dc12bb2b1314766f591129282fd372c855fa877 SHA256 (Python-3.11.0b4.tgz) = 257e753db2294794fa8dec072c228f3f53fd541a303de9418854b3c2512ccbec
Does anyone have the ear of someone at github? It would make testing this beta much easier if they would merge the PR to allow installing 3.11.b4 in github actions: https://github.com/actions/python-versions/pull/177 Samuel Also the GH bot is using DD/MM/YYYY date format :-( whyyyyyy? -- Samuel Colvin 07801160713 On Mon, 11 Jul 2022 at 20:32, Pablo Galindo Salgado <pablogsal@gmail.com> wrote:
Also the GH bot is using DD/MM/YYYY date format :-( whyyyyyy?
Because github is international, and everyone but the US seems to agree that ``` /\ / \ / \ / day \ /________\ / \ / month \ /______________\ / \ / year \ /____________________\ ``` is preferable to ``` __________ / \ / month \ /______________\ /\ / \ / \ / day \ ___/________\___ / \ / year \ /____________________\ ```
On 13/07/2022 12:12, h.vetinari@gmx.com wrote:
I much prefer YYYY-MM-DD (or YYYY.MM.DD) because: 1. It's consistent with HH:MM:SS and other instances where there are multiple units (they go from largest to smallest). 2. It's easier to sort them. 3. It removes the confusion over whether it's DD/MM/YYYY or MM/DD/YYYY.
4. It implements ISO 8601 (which exists for a reason): https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates On 7/14/2022 6:25 PM, MRAB wrote:
Alan G. Isaac writes:
4. It implements ISO 8601 (which exists for a reason): https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates
Yes!!! "Standardization is my Valentine!" :-D -- RIP WotR Bombshell
Since a few people have reacted to my PS comment: I suffered (committed) a very confusing typo; the github bot refers to "07/13/2022" (e.g. MM/DD/YYYY) which drew my ire, I then confusingly referenced a different format in my comment. Overall, I agree we should be using ISO8601 for exactly this reason (at least for dates, for datetimes ISO8601 gets pretty wacky <https://ijmacd.github.io/rfc3339-iso8601/>) Samuel -- Samuel Colvin 07801160713 On Fri, 15 Jul 2022 at 05:39, Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:
Samuel Colvin writes:
I have never had a use for anything but yyyy-mm-ddThh:mm:ss (and very occasionally yyyy-mm-ddZhh:mm:ss for international coordination). What's wacky about that? It's not terribly human-readable, but for humans you can substitute a space for T (Z) and append a timezone or offset if you want to disambiguate. Sure, there is lots of optional syntax in ISO 8601, but when does one need the wacky stuff in a release announcement? Steve
You have: Report bugs at [https://bugs.python.org%5D(https://bugs.python.org). Why not change to https://github.com/python/cpython/issues
participants (7)
-
Alan G. Isaac -
h.vetinari＠gmx.com -
Mike mcleod -
MRAB -
Pablo Galindo Salgado -
Samuel Colvin -
Stephen J. Turnbull