Finally, it’s final! The final release of Python 3.12.0 (final) is here!
(This also means I’ll be unblocking the 3.12 branch soon; I’m just going through pending PRs and merging them sequentially, to avoid some of the churn.)
This is the stable release of Python 3.12.0
Python 3.12.0 is the newest major release of the Python programming language, and it contains many new features and optimizations.
Major new features of the 3.12 series, compared to 3.11
The deprecated wstr and wstr_length members of the C implementation of unicode objects were removed, per PEP 623.
In the unittest module, a number of long deprecated methods and classes were removed. (They had been deprecated since Python 3.1 or 3.2).
The deprecated smtpd and distutils modules have been removed (see PEP 594 and PEP 632. The setuptools package continues to provide the distutils module.
Invalid backslash escape sequences in strings now warn with SyntaxWarning instead of DeprecationWarning, making them more visible. (They will become syntax errors in the future.)
The internal representation of integers has changed in preparation for performance enhancements. (This should not affect most users as it is an internal detail, but it may cause problems for Cython-generated code.)
They have no need of our help
So do not tell me
These haggard faces could belong to you or me
Should life have dealt a different hand
We need to see them for who they really are
Chancers and scroungers
Layabouts and loungers
With bombs up their sleeves
Cut-throats and thieves
They are not
Welcome here
We should make them
Go back to where they came from
They cannot
Share our food
Share our homes
Share our countries
Instead let us
Build a wall to keep them out
It is not okay to say
These are people just like us
A place should only belong to those who are born there
Do not be so stupid to think that
The world can be looked at another way
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.
Discourse managed (at least on my browser) to add a scroll bar, so that the whole of this poem was visible apart from the critical “(now read from bottom to top)” line
It’s only because I followed the link to the original that I spotted it!
I wanted to quickly comment here that conda-forge has – for the first time – managed to have launch-day availability of the new Python version and >1000 packages.
In the end I decided this fits better as a separate post, but to avoid that it gets “hidden” only in the packaging category, I hope people don’t mind that I reference it from here as well.
I’ll also note here that many packages also seem to already have binaries on PyPI - numpy, scipy, matplotlib, pywin32, pillow, pandas, …
Thanks to everyone who puts so much effort into making the lives of early adopters like me so pleasant!
Edit: I just did a quick check, and there are 912 projects with Python 3.12 wheels already. There’s also 669 projects with abi3 wheels, which will work on Python 3.12 as well. In total, there’s 298,057 projects already available on PyPI with Python 3.12 compatible wheels (obviously that latter number is mostly pure Python projects, though).
So the button at the top points towards installing Python 3.12 but the other information on the page all seems to indicate that 3.12 is in prerelease status which seems inconsistent.
Separately I wonder whether it is a good idea that the big yellow button recommends Python 3.12 on day one of release given that some packages will not be installable yet on 3.12. This page is first hit in a web search for “download python” but for now I would consider that 3.12 is still for early adopters rather than the version that I would recommend for any potential new Python users.
We try and emphasize that RC is the time for early adopters, including anyone who maintains a package that ought to be available on day 1. Switching over the default as soon as it releases is consistent with that.
Otherwise, once we start on the slope of “3.12.(n+1) is the new 3.12.n”, we won’t ever have a stable release
There’s no perfect answer here. Yes, at the point X.Y is actually released, it’s correct to say the team believes that to be the best, most performant release. At the same time, it’s also true that at that moment, the entire ecosystem will not have caught up. It’s unreasonable to expect that to happen (though this release seems to have had a lot more important packages be ready by release date than in previous cycles, which is superb progress, by the way).
So, not sure what one should say - maybe some footnote on a .0 release that third-party packages may not be available, check with them?
Such a footnote would only appear on the detailed downloads page, and the “problem” is people clicking on the quick download button without reading the details. So we can’t really win.
There are a few places we do make this decision. For example, the Windows ARM64 build isn’t put on the download button and isn’t in the Windows Store, since it’s too hard for libraries to support it yet. It’s marked experimental at the place where you could download it, but there aren’t any shortcuts (and x64 emulation is good enough that most users will have a better time with the x64 build and libraries than the native build without libraries).
Probably the most useful thing would be if/when pip switches to only installing wheels by default, it might be able to error out saying “no wheels for this version of Python, but they exist for earlier versions” (if that’s the case). That will be better than getting an obscure compiler error, which is how most problems are going to present.
This is true but I also expect this release to have a longer tail of packages that will take more time to catch up. I personally maintain a package python-flint for which the removal of distutils and numpy.distutils means that significant work is needed to be able to support Python 3.12. I can’t say right now when that would happen. I estimate that about 2 days of work are needed but I don’t have that time right now.
It sounds like you’re talking about “feature release” as in Semantic Versioning?
Python itself doesn’t use standard Semantic Versioning. The “second part of the dotted decimal” is apparently officially called the “minor” component of the version number, as in major.minor.micro. See https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work for what I assume is the official statement on the matter - but it doesn’t go into specifics other than the changes will be “less earth-shattering”.
In practice, backwards-incompatible changes do actually happen in minor releases (they’re pretty carefully planned in accordance with PEP 387 – Backwards Compatibility Policy | peps.python.org , and don’t happen often). But the fact that backwards-incompatible changes exist, on purpose, means that these are not “feature releases” as I think you might be expecting.
I would be fine with calling it the “newest minor release” too, but I can understand that it carries connotations that don’t feel right. The language in the announcements is “major release” which doesn’t match up with other parts of the documentation.
Regarding “feature release”, that solution was from the discussion in this issue and this one.
The same discussion happened 5 or 10 years ago with none of the same participants as the discussions you’re pointing to! Python doesn’t follow semver but it is fine and good to use the terms feature release and bugfix release for clarity.
I’m not sure where is the correct place to post this, but the /layout flag is broken on the 64-bit windows installation executable. It seems to fail due to outdated hashes.
