Hello! My apologies if I’ve posted this in the wrong category, I wasn’t sure whether this was “ideas” or “packaging.”
I was wondering whether the core developers were thinking about dropping Python prebuilt installers for 32 bit Windows in 3.12 or upcoming versions. I noticed that the 3.11 release has pioneered a new ARM64 windows installer. Presumably Windows on ARM will pick up over the next couple years, so maintainers of C extensions will want to have prebuilt wheels for that platform. C extension maintainers also (in my experience) want to support 32 bit Windows installs because they are standard Python installations from python.org
But very few people actually need 32 bit Windows installations anymore, and not feeling the need to make 32 bit wheels would simplify workflows for C extensions. Especially C extensions that rely on external libraries, which need to be compiled separately into 32 bit and 64 bit versions.
Article from 2.5 years ago about Windows discontinuing any new 32 bit Windows installs-- It's the end of an era as Microsoft stops distributing 32-bit Windows | PC Gamer
The Steam Hardware survey “OS Version” section shows 32 bit installs are very rare in the current day-- Steam Hardware & Software Survey
Ceasing to provide 32 bit Windows installations in upcoming versions of Python will let C extension maintainers off the hook for providing 32 bit wheels, eventually simplifying wheels generation, which will be nice because ARM64 support will eventually be complicating Windows wheel generation by requiring multi arch (like Mac now).
I found a previous discussion on this topic: Dropping 32-bit packages
Particularly of note in that discussion was Steve Dower’s statement that once ARM64 starts being supported win32 can be dropped-- Dropping 32-bit packages - #2 by steve.dower
To be clear, I was referring there to packages choosing to drop their own 32-bit builds. There are no plans to drop 32-bit releases of CPython for Windows, and if there were, it would be nothing to do with ARM64 (and everything to do with Windows dropping support for 32-bit executables - which to my knowledge has not even been discussed, let alone been planned).
You have to differentiate between Windows 32-bit OS installations and Windows 32-bit applications (x86). The latter run perfectly well on 64-bit Windows versions (x64) and are still in common use – just check your
C:\Program Files (x86) folder.
To be clear, I was referring there to packages choosing to drop their own 32-bit builds
Sorry for misrepresenting your point, my mistake.
If Python continues to make 32 bit installers for Windows, I don’t think many packages will choose to drop those builds. When a user tries to pip install the package and it fails (because most people don’t have a a C compiler on Windows) they’ll open a bug ticket, and then the package will either say that they don’t support this completely valid Python installation or somebody will go back to the cibuildwheel (or whatever) config and re-add the build.
Python making the call lets the packages off the hook and transitions the whole ecosystem over several Python release cycles.
In the previous discuss, mattip, maintainer of numpy said:
I realize each project could have its own support policy, but a python-wide statement would be more convincing
And Python dropping future installers for win32 would be a convincing python-wide statement.
You have to differentiate between Windows 32-bit OS installations and Windows 32-bit applications (x86).
My point was that very few people need a 32 bit install, since 32 bit Windows needs 32 bit programs but 64 bit Windows could run either.
I haven’t personally run into this problem for a while, but it would not surprise me if there are extension modules that link to vendor-provided libraries that are only available in 32 bit versions.
I think they are already considering themselves off the hook, e.g. PyTorch doesn’t ship 32-bit wheels for any platform.