[RELEASE] Python 3.8.10, 3.9.5, and 3.10.0b1 are now available
This has been a very busy day for releases and on behalf of the Python development community we’re happy to announce the availability of three new Python releases. Python 3.10 is now in Beta Get it here: Python 3.10.0b1 <https://www.python.org/downloads/release/python-3100b1/> Python 3.10 is still in development. 3.10.0b1 is the first 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.10 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> 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 4 and as few code changes as possible after 3.10.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.10 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. The next pre-release, the second beta release of Python 3.10, will be 3.10.0b2. It is currently scheduled for 2021-05-25. Please see PEP 619 <https://www.python.org/dev/peps/pep-0619/> for details. Development Begins on Python 3.11 With Python 3.10 moving to beta, it received its own 3.10 branch in the repository <https://github.com/python/cpython/>. All new features are now targeting Python 3.11, to be released in October 2022. Using the opportunity with the creation of the 3.10 branch, we renamed the master branch of the repository to main. It’s been a bit rocky <https://github.community/t/renaming-python-master-branch-to-main-1-4k-prs-700-repositories-triggered-server-http-error-500/178090> but looks like we’re open for business. Please rename the main branch of your personal fork using the guide GitHub will give you when you go to your fork’s main page. In case of any outstanding issues, please contact the 3.11 RM <https://devguide.python.org/devcycle/#current-administrators>. Python 3.9.5 Get it here: Python 3.9.5 <https://www.python.org/downloads/release/python-395/> Python 3.9.5 is the newest major stable release of the Python programming language, and it contains many new features and optimizations. There’s been 111 commits since 3.9.4 which is a similar amount compared to 3.8 at the same stage of the release cycle. See the change log <https://docs.python.org/release/3.9.5/whatsnew/changelog.html> for details. On macOS, we encourage you to use the universal2 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 future 3.9.x releases. You may need to upgrade third-party components, like pip, to later versions once they are released. 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 <https://bugs.python.org/> for existing reports and for opening new issues. The next Python 3.9 maintenance release will be 3.9.6, currently scheduled for 2021-06-28. The Last Regular Bugfix Release of Python 3.8 Get it here: Python 3.8.10 <https://www.python.org/downloads/release/python-3810/> According to the release calendar specified in PEP 569 <https://www.python.org/dev/peps/pep-0569/>, Python 3.8.10 is the final regular maintenance release. Starting now, the 3.8 branch will only accept security fixes and releases of those will be made in source-only form until October 2024. To keep receiving regular bug fixes, please upgrade to Python 3.9. Compared to the 3.7 series, this last regular bugfix release is relatively dormant at 92 commits since 3.8.9. Version 3.7.8, the final regular bugfix release of Python 3.7, included 187 commits. But there’s a bunch of important updates here regardless, the biggest being macOS Big Sur and Apple Silicon build support. This work would not have been possible without the effort of Ronald Oussoren, Ned Deily, Maxime Bélanger, and Lawrence D’Anna from Apple. Thank you! Take a look at the change log <https://docs.python.org/release/3.8.10/whatsnew/changelog.html> for details. We hope you enjoy the new releases 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> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>
- Cython doesn't work because of _PyGen_Send change [1]
I think this is fixed on the latest cython (0.29.23) On Wed, 26 May 2021 at 01:05, Neil Schemenauer <nas-python@arctrix.com> wrote:
On 2021-05-04, Łukasz Langa wrote:
We strongly encourage maintainers of third-party Python projects to test with 3.10 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible.
Testing with Python 3.10b1 is not easy, at least for me. Here is a list of initial problems I ran into, from memory:
- Cython doesn't work because of _PyGen_Send change [1]
- scipy cannot be installed because it has requires_python = ">=3.7,<3.10". If you manually install from source, it seems to work.
- numpy cannot be installed because of _Py_HashDouble() change [2]
- trio cannot be used because of TracebackException.__init__ changes [3]
For the above problems, I would suggest the 3rd party package has the issue and it's not a problem with the Python release. However, I guess that few people are using Python without 3rd party packages. So, it seems unsurprising that beta and RC releases are not well tested. It has taken me quite a few hours to get a working version of Python 3.10 with all required dependancies such that I can run unit tests for some application code.
Can we do any things to improve the situation? Perhaps using the pre-release functionality of PyPI would help. We would have to somehow encourage 3rd party packages to upload pre-releases that are compatible with our beta/RC releases.
1. https://github.com/cython/cython/issues/3876 2. https://github.com/numpy/numpy/issues/19033 3. https://github.com/python-trio/trio/issues/1899 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/2Z23GRYT... Code of Conduct: http://python.org/psf/codeofconduct/
On 2021-05-04, Łukasz Langa wrote:
We strongly encourage maintainers of third-party Python projects to test with 3.10 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible.
Testing with Python 3.10b1 is not easy, at least for me. Here is a list of initial problems I ran into, from memory: - Cython doesn't work because of _PyGen_Send change [1] - scipy cannot be installed because it has requires_python = ">=3.7,<3.10". If you manually install from source, it seems to work. - numpy cannot be installed because of _Py_HashDouble() change [2] - trio cannot be used because of TracebackException.__init__ changes [3] For the above problems, I would suggest the 3rd party package has the issue and it's not a problem with the Python release. However, I guess that few people are using Python without 3rd party packages. So, it seems unsurprising that beta and RC releases are not well tested. It has taken me quite a few hours to get a working version of Python 3.10 with all required dependancies such that I can run unit tests for some application code. Can we do any things to improve the situation? Perhaps using the pre-release functionality of PyPI would help. We would have to somehow encourage 3rd party packages to upload pre-releases that are compatible with our beta/RC releases. 1. https://github.com/cython/cython/issues/3876 2. https://github.com/numpy/numpy/issues/19033 3. https://github.com/python-trio/trio/issues/1899
Hi, On Wed, May 26, 2021 at 2:05 AM Neil Schemenauer <nas-python@arctrix.com> wrote:
- Cython doesn't work because of _PyGen_Send change [1]
My team fixed the Python 3.10 compatibility in the Cython 0.29.x branch, but the latest 0.29.x release (0.29.23, April 14, 2021) doesn't include these fixes yet. A new Cython release is needed. I'm not sure how to help Cython to release a new version. In Fedora, we have downstream patches until a new Cython is released: https://src.fedoraproject.org/rpms/Cython/pull-request/28
- numpy cannot be installed because of _Py_HashDouble() change [2]
"pip install numpy" also fails with an error about "incompatible tag". It's an issue in packaging which is vendored in wheel which is used (as a vendored copy?) by pip to build a local wheel package of numpy. numpy doesn't ship wheel packages for Python 3.10 beta releases which is a good idea, the ABI is not stable yet.
Can we do any things to improve the situation? Perhaps using the pre-release functionality of PyPI would help. We would have to somehow encourage 3rd party packages to upload pre-releases that are compatible with our beta/RC releases.
In Fedora, we use a "COPR build": we partially rebuild the OS with Python 3.10, and then we check for package build failures. We are working on switching to Python 3.10 by default: * https://fedoraproject.org/wiki/Changes/Python3.10 * https://bugzilla.redhat.com/show_bug.cgi?id=1890881 For example, my colleague Lumir submitted the trio bug report ;-) https://github.com/python-trio/trio/issues/1899 We are doing our best to report issues to projects. Sometimes we help to fix them, but we cannot fix all compatibility issues! In the past, I tried to work on a small Python script to run the test suite of some projects with the main branch of Python. I had practical issues: * There is no simple way to get install test dependencies of a Python project, especially non-Python dependencies. * When a dependency was not compatible with the next Python, I had to maintain a patch until my fix is accepted upstream. * Sometimes, I had to pull the code from Git rather than using a tarball/ZIP (to not have to wait for a new release). At the end, all these practical issues need solutions which look very closely to a recipe to build a package for a Linux distribution: * Recipe to pull the source. * Recipe to pull build dependencies. * Downstream patches (until a fix is merged upstream). * Recipe to run tests: we try to always run tests when we build a package in Fedora. Advantages of using Fedora COPR: * Reuse Fedora infrastructure (building packages need physical servers to build packages and run tests) * Reuse the public Fedora bug tracker to coordinate the work. * Reuse Fedora "specfiles" (recipe to build a RPM package). * Prepare Fedora to be updated to the next Python. Sadly, Fedora COPR might be a little bit too Fedora specific: require to understand specfiles, how to submit a PR on a specfile, use the Fedora bug tracker, etc. Fedora Rawhide was just updated to switch Python 3.10 by default! /usr/bin/python3 is now Python 3.10 beta2. In COPR we could skip tests to build dependencies and discover more compatibiliy issues. In Rawhide, tests cannot be skipped and so some packages cannot be built yet. For example, astropy has a few failing tests: https://github.com/astropy/astropy/issues/11821 Again, the practical problem is that numpy cannot easily be installed on Python 3.10 (pip compatibiltiy tag issue), and so astropy may wait until Python 3.10 final is released to look into these tests failures. Victor -- Night gathers, and now my watch begins. It shall not end until my death.
For "pip install numpy", a new numpy release should fix the issue. The issue was already fixed in packaging 20.8: * https://github.com/pypa/packaging/commit/611982be44d7d91453a97082f58d8ea349f... * https://github.com/pypa/packaging/pull/355 The fix is already included in wheel 0.36.2 (which includes a vendored copy of packaging): * https://github.com/pypa/wheel/commit/f6fd2472c7a4a836a3ebe12eab96a1ed8a31c06... And numpy pyproject.toml was updated to use wheel 0.36.2 which contains the fix: * https://github.com/numpy/numpy/commit/9569f40917c80b9506f0969b1e89e2fc119d4a... The pyproject.toml fix is not part of 1.20.3: https://github.com/numpy/numpy/blob/v1.20.3/pyproject.toml -- I didn't even know that it was possible to require a specific wheel version in pyproject.toml to build a binary wheel package in pip! Current pyproject.toml: https://github.com/numpy/numpy/blob/main/pyproject.toml [build-system] # Minimum requirements for the build system to execute. requires = [ "packaging==20.5; platform_machine=='arm64'", # macos M1 "setuptools<49.2.0", "wheel==0.36.2", "Cython>=0.29.21,<3.0", # Note: keep in sync with tools/cythonize.py ] Victor On Fri, Jun 11, 2021 at 4:30 PM Victor Stinner <vstinner@python.org> wrote:
Hi,
On Wed, May 26, 2021 at 2:05 AM Neil Schemenauer <nas-python@arctrix.com> wrote:
- Cython doesn't work because of _PyGen_Send change [1]
My team fixed the Python 3.10 compatibility in the Cython 0.29.x branch, but the latest 0.29.x release (0.29.23, April 14, 2021) doesn't include these fixes yet. A new Cython release is needed. I'm not sure how to help Cython to release a new version.
In Fedora, we have downstream patches until a new Cython is released: https://src.fedoraproject.org/rpms/Cython/pull-request/28
- numpy cannot be installed because of _Py_HashDouble() change [2]
"pip install numpy" also fails with an error about "incompatible tag". It's an issue in packaging which is vendored in wheel which is used (as a vendored copy?) by pip to build a local wheel package of numpy. numpy doesn't ship wheel packages for Python 3.10 beta releases which is a good idea, the ABI is not stable yet.
Can we do any things to improve the situation? Perhaps using the pre-release functionality of PyPI would help. We would have to somehow encourage 3rd party packages to upload pre-releases that are compatible with our beta/RC releases.
In Fedora, we use a "COPR build": we partially rebuild the OS with Python 3.10, and then we check for package build failures. We are working on switching to Python 3.10 by default:
* https://fedoraproject.org/wiki/Changes/Python3.10 * https://bugzilla.redhat.com/show_bug.cgi?id=1890881
For example, my colleague Lumir submitted the trio bug report ;-) https://github.com/python-trio/trio/issues/1899
We are doing our best to report issues to projects. Sometimes we help to fix them, but we cannot fix all compatibility issues!
In the past, I tried to work on a small Python script to run the test suite of some projects with the main branch of Python. I had practical issues:
* There is no simple way to get install test dependencies of a Python project, especially non-Python dependencies. * When a dependency was not compatible with the next Python, I had to maintain a patch until my fix is accepted upstream. * Sometimes, I had to pull the code from Git rather than using a tarball/ZIP (to not have to wait for a new release).
At the end, all these practical issues need solutions which look very closely to a recipe to build a package for a Linux distribution:
* Recipe to pull the source. * Recipe to pull build dependencies. * Downstream patches (until a fix is merged upstream). * Recipe to run tests: we try to always run tests when we build a package in Fedora.
Advantages of using Fedora COPR:
* Reuse Fedora infrastructure (building packages need physical servers to build packages and run tests) * Reuse the public Fedora bug tracker to coordinate the work. * Reuse Fedora "specfiles" (recipe to build a RPM package). * Prepare Fedora to be updated to the next Python.
Sadly, Fedora COPR might be a little bit too Fedora specific: require to understand specfiles, how to submit a PR on a specfile, use the Fedora bug tracker, etc.
Fedora Rawhide was just updated to switch Python 3.10 by default! /usr/bin/python3 is now Python 3.10 beta2. In COPR we could skip tests to build dependencies and discover more compatibiliy issues. In Rawhide, tests cannot be skipped and so some packages cannot be built yet. For example, astropy has a few failing tests: https://github.com/astropy/astropy/issues/11821
Again, the practical problem is that numpy cannot easily be installed on Python 3.10 (pip compatibiltiy tag issue), and so astropy may wait until Python 3.10 final is released to look into these tests failures.
Victor -- Night gathers, and now my watch begins. It shall not end until my death.
-- Night gathers, and now my watch begins. It shall not end until my death.
participants (4)
-
Neil Schemenauer -
Pablo Galindo Salgado -
Victor Stinner -
Łukasz Langa