Please see my comment further above. It’s not just people embedding Python into a 32-bit application, it’s also people wanting to interface to 32-bit applications via direct linking.
The ODBC database standard is one such standard that requires linking to drivers, which in return link to data drivers. Windows provides both 32-bit and 64-bit drivers and the two worlds are completely separate. Just to give one example.
If you have to work with older Access database, or interface to older MS Office packages in general, 32-bit is still the way to go. The same goes for many applications in e.g. the medical space. Some of these industries are often slow when it comes to upgrading.
I’m not saying 32-bit is a top priority, but making it look like only embedders could possibly have a need for this, is not painting the full picture. There still are valid use cases for it.
I hope there aren’t many OEMs shipping a system with Windows 32-bit with 8GB of memory
Reminder that Python 3.12 still has some life left in it, so users who need to run 32-bit applications on Windows would have until 2028 before support expires, 3 years after Windows 10 generally becomes end-of-life
If if I may propose a summary of the discussion so far:
the python.org downloads and Windows pages should recommend the 64-bit installer over the 32-bit one, so that people don’t use the latter by mistake
there are genuine cases for a 32-bit Python on Windows, including embedding in 32-bit applications and linking with 32-bit ODBC drivers
developing and testing on 32-bit Windows is not significantly different from developing and testing on 64-bit Windows: if you can do the latter, you can also do the former (even in the same 64-bit VM, probably)
32-bit platforms in general are not going away soon, so Python will still have to ensure general 32-bit compatibility even if it were to drop 32-bit Windows support
the cost of supporting 32-bit Windows specifically is probably not very high for CPython
Which, IMHO, brings the final question: what good would it do to downgrade 32-bit Windows support to a lower tier?
Are people accidentally downloading 32 bit python on a 64 bit platform?
Some information about this can be gleaned from the User-Agent information in the python.org server logs or js-based statistics. Parsing user agents has gotten increasingly weird over time, but answering this specific question is probably still straightforward.
Yes, people have told us it happens. When it does, it adds user friction.
I wish we had a universal windows installer instead of the six different windows download options. Someone willing to do windows specific work would have to figure out how to (re)arrange our release process to make such a thing happen. (Is that even a common windows concept?)
I created this issue when I saw Windows x86 failures time to time. All CIs (especially Windows) were affected by test_concurrent_futures bug: the test hangs, is killed after 20 min timeout, then is re-run, and again is killed by timeout after 20 min: in total, over 40 min are wasted because of my second point.
These Windows x86 failures didn’t prevent to merge a PR since the GitHub Action job is not mandatory. Problem: this job MUST complete… even if it fails, before a PR can be merged For me, it’s a little bit surprising that Windows 32-bit is a Tier-1 platform but its GHA job is not mandatory.
Well, as Brett explained before, macOS is in a similar state: non-voting (not mandatory) GHA job since the job is slow (and was kind of unstable, don’t know if it’s still the case or not).
But other people raised other concerns about Windows 32-bit support: see other previous messages in this topic.
I’m not sure that’s true. E.g. I think if you schedule “automerge”, the PR will be merged once all the required jobs have succeeded, whether or not the non-required jobs have completed. And I don’t think automerge has any ability to merge things when you wouldn’t be able to otherwise.
Auto-merge only merges a PR once all mandatory jobs complete and are successful. Currently, there is a “All required checks pass” job which only starts with all other jobs, including not mandatory jobs like Windows x86, complete. In practice, a PR cannot be merged until Windows x86 completes… even if it fails. I suppose that it can be changed.
The “All required checks pass” job was added since changing the configuration of the GitHub cpython project was complicated. I suppose that it’s not easy to mark a job as mandatory on some Git branches, and not mandatory on other branches. Also, core devs don’t have access to these options, only the few people have access to the GitHub admin page.
That would push the six options to the first step when the user runs the installer, and would also bloat the installer to the total size of all options (we used to have a download-on-demand installer but users didn’t care for it).
Based on the change before and after we changed the default download button on the website (which I don’t have handy now, sorry), something like 95% of downloads just use that button. So the vast majority of users have no risk of selecting the wrong item from the full download list.
Thanks, I wasn’t aware that the new “All required checks pass” job had changed things in this regard! Sorry for not checking before posting misinformation
Tests failing on some after a bugfix: that’s not good, please fix*… because the alternative is not to release the bugfix at all, on select platforms or on all platforms.
*) as an organisation, someone needs to fix it, not necessarily the developer who submitted the bugfix
This would be somewhat alleviated - see also other comments here where this would be of benefit - if the python.org installer for Windows was a 32-bit stub, which, when run, would download for ‘correct’ Python version - or at least suggest the ‘correct’ version(s) for the user’s OS version.
That’s exactly what it is, but unfortunately it needs a rewrite from scratch without the help of the WiX toolset in order to handle that kind of choice. The WiX toolset provides all the registration, detection, upgrade and repair logic, but is also limited in that it has to know which packages will be installed at compile time (it’s possible to list them all and then omit them later, but that has its own set of complexities). A single bundle that includes all the 32-bit and 64-bit and ARM64 packages is possible, but huge (if compressed) or unreliable (if download-on-demand), and likely unreliable in a number of other areas too (feature on/off selections leading to registry/environment inconsistencies, etc.).
I don’t think there’s a worthwhile return on rewriting the entire installer. If we’re going to make big changes there, I’d rather simplify it down to a less user-friendly experience and push on the Store package as the “just give me Python” option.
By “less user friendly” I mean:
don’t run ensurepip on install
don’t precompile .pyc on install
don’t allow “Repair” - “uninstall” just becomes deleting the entire install directory and registry keys
don’t allow feature on/off selections
don’t download on demand
don’t modify environment variables
don’t upgrade existing installs (maybe offer to delete all the old files before overwriting if the user chooses the same directory)
don’t offer a per-user/all machine choice (except at the command line)
don’t bundle the launcher (make that a separate installer, it can keep the file associations etc.)
So basically, if you get our main installer (which I often call the “Python Development Kit”), then you get everything. We get a much easier to maintain installer - basically a self-extracting ZIP - and a number of long standing bugs actually just go away.
People who want a user-friendly experience on Windows get it from the Windows Store, which installs quicker, properly handles global aliases,[1] detects the user’s platform, automatically updates, and is properly secured against people breaking their own install.
Well, almost. But what remains there are acknowledged bugs/limitations in the OS and are not our fault. ↩︎
Example of tests which I saw failing on GHA Windows x86, but not on other platforms: test_concurrent_futures: test_as_completed.test_future_times_out(). Hum, I should add --fail-rerun when running tests on the main branch, maybe this test fails on other platforms.
test_threading.BarrierTests.test_default_timeout() also fails randomly on Windows x86, but it fails also on Windows x64. The failure can be reproduce on other platforms, but it’s just less harder to trigger on other platforms.
I haven’t looked, but does the Windows Store allow installing multiple versions of Python?
I’m personally OK with the idea of “only advanced users need multiple versions of Python installed”, but whenever I make that claim, I seem to get pushback from people that there are plenty of use cases where having multiple Python versions can’t be viewed as an “expert only” situation. So I don’t think we can downgrade the python.org installer UX unless we’re sure that the Store version is fine for all use cases “ordinary users” will encounter.
On which note, many corporate installations block (or limit) Windows Store access. And yet those corporate policies are frequently remote from the needs of actual developers, meaning that people who need Python might not have the option to use the Store.
Each major version is its own app, so yeah, they can all install side-by-side. The “Manage app execution aliases” settings page lets you choose which one gets the python.exe name, but they all have a python3.12.exe equivalent (and for pip/idle too).
Many also block regular installers, or set policies that cause them to break in weird ways. Anyone managing Windows Store access has the option to allow Python, or to copy it into their internal Store (there’s an option to disallow this, which I explicitly never select). If they refuse to support their own devs, that’s a process problem that we can only really help with by releasing high quality installers (e.g. code signing with our own cert gets us into many places that would block us). There are bugs with the traditional installer that prevent some enterprises deploying Python more widely, but we can’t resolve them without breaking other users, or adding more installers to the list.
If we didn’t already have “too many” download options then I’d publish the “side-loadable” MSIX package,[1] which lets you copy the package locally and then install it. Again, it can be blocked by policies, but generally that setting is separate from access to the whole Store.
The equivalent of what gets published to the Store, but signed by us and can be double-clicked to install. ↩︎
For me, it’s a little bit surprising that Windows 32-bit is a Tier-1 platform but its GHA job is not mandatory.
