Consider downgrading Windows 32-bit from Tier-1 to Tier-2 or Tier-3? (in Python 3.13?)

I think it would make sense to update the Python Windows page as @hugovk mentioned to list 64-bit as preferred unless you have a 32-bit system or need to run 32-bit applications.


I think all WebAssembly builds are 32-bit.

Regardless of whether i686-pc-windows-msvc/msvc should be Tier 1, I’m surprised that macOS and Windows (x86) aren’t required jobs. Has it always been this way? It seems like it’s missing the spirit of PEP 11’s requirements for a Tier 1 platform:

  • CI failures block releases.
  • Changes which would break the main branch are not allowed to be merged; any breakage should be fixed or reverted immediately.
  • All core developers are responsible to keep main, and thus these platforms, working.

My mental model for the support tiers has always been something like:

  • Tier 1: Required CI check that all contributors need to care about. No merging failures.
  • Tier 2: Buildbots that all core devs need to care about. Revert or fix failures quickly.
  • Tier 3: Buildbots that one or more core devs need to care about. In theory, these can stay red forever.

(For example, my understanding is that the lack of CI resources is the main reason why aarch64-apple-darwin/clang isn’t Tier 1.)

1 Like

Agreed with about half the points suggested in this thread :slight_smile: Rather than quote lots of people, I’ll summarise:

  • Windows fully supports running 32-bit executables, and in some scenarios requires it. The platform has not gone away.
  • Assuming that CPython can dictate the process architecture that users use is the height of arrogance. (This is my own point, nobody else said this :wink: ) We should support what users need, rather than assuming that if we change, they’ll all change.
  • If people are confused by the web page, let’s fix the web page. That bears no relation to what we test or release.
  • Windows is not the only 32-bit platform. We don’t get to remove codepaths by dropping it.
  • If people are unavailable to work on Windows 32-bit issues, they are largely unavailable to work on Windows 64-bit issue and Windows ARM64 issues, as there is very little difference between the platforms. Perhaps we need to increase our recruitment efforts in this direction?
  • Windows 32-bit ought to be a required check right now. This discussion is about making it non-required, so the fact that it’s currently not required kinda nullifies it.
1 Like

Correct, although there is a proposal for 64-bit index size for memory. There’s some support, but it’s all gated behind a flag or not released yet.


Is it because they have a 32-bit CPU? Is it because they have a 32-bit OS on a 64-bit CPU? Are they running a 32-bit Python on a 64-bit OS?

first, answering the question (TL;DR - despite this we can shift it down to tier-3 for 3.13):

(1) Because 32-bit applications are still supported on Windows and some people may be using embedded Python to interface in-process with those. The case of embedding Python in an extension to one such application came up in another conversation recently IIRC. People needing embedded Python require a Python that matches. But I assume embedders are also more likely to be people capable of doing their own builds.

(2) Do understand that Microsoft only stopped allowing OEMs to ship 32-bit Windows 10 in May of 2020. Before then some still were on lower end system configurations usually with <=8G RAM. It had nothing to do with what the CPU itself supports (the last 32-bit-only x86 was ~15+ years ago). Those shipped-with 32-bit windows 10 computers still exist. Users are usually not aware and won’t figure out how to upgrade without being forced to. BUT their number seems few (good, because i think they no longer get security updates?):

Per Dropping 32-bit packages - #13 by hugovk in May this year Hugo found that PyPI downloads for Windows numpy were <2% 32-bit x86, and if you focus on recent >= 3.10 Pythons only - the number was < 1%.

That is reassuring!

So we should be able to stop considering 32-bit x86 in 3.13 a priority (kick it down to tier 3 if we’ve still got a buildbot). That’d put it in the same category as arguably much more important to the world, tier-3 aarch64 (arm64) Windows.

PEP 11 – CPython platform support | would need to be updated to mention this change for 3.13+.

1 Like

Yeah… what I’d like to see, if we seriously want to keep 32-bit windows x86 a high-tier status, is a significant set of widespread practical applications that need it. The wider Python ecosystem has already dropped 32-bit Windows support, so who are these users who need new Python releases but not a functioning ecosystem?

At this point it feels like the only ones that would are people embedding it in code that needs to be loaded by a 32-bit process? I expect embedders are the kind of people we should just tell to build their own 32-bit windows x86 cpython from source.

If anyone know them, having them speak up here with rationale about why they need 3.13+ to work on 32-bit x86 windows would be helpful. volunteering time and resources to make it happen would be more so.

1 Like

There was a practical matter of those CI systems being either (a) flaky or (b) super slow in the past (why not both? meme), holding changes that have no platform specifics up in the past. If, for example, macOS is no longer flaky we should make it required. Merge queues mostly resolve the super slow annoyance as when a change is ready it can be queued to automerge once the slow long-tail CI runs finish.

Just on this point, I’m not aware of any 32-bit specific issues on Windows outside of libffi. The one that Victor raised was not at all related to the platform, and would have impacted any platform that used our stack probing support (which isn’t that reliable on Windows anyway and should really just be removed).

The time and resources would be best directed to flaky tests, which are going to flake more often when run twice (both 32-bit and 64-bit), but are not specific to 32-bit Windows. More time and resources for 32-bit won’t help anything more than more contributors in general. The most useful thing a 32-bit specific contributor could do would be to go work on libffi or OpenSSL.

Edited to add the main benefit of dropping 32-bit support would be that we can add code that breaks on 32-bit, which also prevents people from building it from source. So when we’re prepared to fully abandon those users/embedders/whoever, we should communicate it as “the platform no longer works”, not “we aren’t releasing binaries or testing in PRs”.


From what I read, what is needed is a better guidance for users landing on Python download page. Honestly, I would prefer to put Windows 32-bit installer on a separated page. Linux distribution usually have an obvious download choice for the supported default setup: single big [Download] button and no choice, but still provide “alternative” choices in a separated page, like different desktop environment (KDE and XFCE, instead of Gnome). Maybe it doesn’t have to be on a separated page, but just “below” on the same page. It’s an UI issue :slight_smile: Like “if you need to access 32-bit app, consider using Python 32-bit”. Something like that.


If you want to agree with me, feel free to quote the part that you agreed with :wink:

1 Like

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 :smiley:

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 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?


The one thing we’re all in agreement on is that the downloads page needs revamping so that 32-bit x86 windows downloads are separated out and noted as not being what most people want. That is tracked in the old List 64-bit Windows Installer Above 32-bit Windows embedded · Issue #2194 · python/pythondotorg · GitHub issue. It’s a matter of having someone do it.


Please see PR python/pythondotorg#2311.


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 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 guess the more important number is how many people download 32 bit python on an actual 32 bit os.

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 :frowning: 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.