Where would be an appropriate place to discuss dropping 32-bit packages across the python ecosystem? Neither the Redhat, the windows store nor conda-forge support any 32-bit variants, and producing packages doubles CI time for all library packagers. I realize each project could have its own support policy, but a python-wide statement would be more convincing. Specifically, I would like to drop windows 32-bit PyPI wheels from the scientific python stack, is that OK?
My main concern is that would leave Windows ARM64 users out in the cold, as they can run 32-bit binaries (emulated) but not 64-bit. And there’s a surprising amount of demand out there - literally everyone who’s asked me why there’s no 32-bit build on the Store (still only 5-6 people) has wanted it for ARM64.
Obviously native builds are better, and I’m working behind the scenes to get CI support for it (which is blocked on having native Python support 
but at least that’s internal from my POV so I can slip them a build) and there’ll need to be some tooling improvements to handle cross-compilation (no ARM64-native compilers), but eventually it’ll all pull together. I’ve been holding off releasing a native CPython build here until there’s a way for the ecosystem to match.
So I think dropping 32-bit will be fine once we’re ready to pick up ARM64 
IIUC, I think by 32-bit, @mattip is referring to x86 in particular. @steve.dower has provided the answer for Windows, and macOS doesn’t support x86 anymore, so I just want to chime in that most distro supporting x86 (and other obscure architectures) have their own CI systems for downstream testing and building.
Ideally, it would be great to warn any embedders who are including them in 32-bit apps, though I know those are hard to find. Chances are they won’t easily be able to just switch their app to 64-bit, and if they’re dependent on a numpy stack it could come as a surprise. (That said, most embedders seem happy enough to be a few versions behind anyway to keep the stability. So likely not going to have any painful blowback if they find out with everyone else.)
Have you checked the download stats for the existing 32-bit wheels?
There’s also the fact that the default Windows download has been 32-bit for a long time, so the number of Windows users with 32-bit Python will be artificially inflated. 3.9 is 64-bit by default, so things are easier there. But for 3.8 and earlier, dropping 32-bit builds of new project releases would impact all of those 32-bit users, even though they might be perfectly able to run 64-bit Python.
1 Like
That will hopefully change soon:
Even so, plenty of people want Python for truly native things, and we want to offer it.
Though it would certainly be easier to tell people to use x64 if they want a Python data stack, and use ARM64 if they want a native Python runtime.