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

Core Development
1

Right now, supporting the Windows x86 (32-bit) platform is the responsibility of all core developers: it’s a Tier-1 platform. I’m not comfortable with this status: I’m not sure that “all core devs” have access to a Windows machine to build Python in 32-bit mode and debug issues (specific to this platform).

Recently, I fixed a RecursionError in test_tomllib and backported my fix to Python 3.11. On Python 3.11, it’s fine on all platforms, except on Windows x86 where test_support and test_tomllib are now failing. Well, it’s likely not a bug deal to fix this issue, it’s just an example. Since the “Windows x86” job is not mandatory on pull requests, I merged my PR. @steve.dower proposed his help to fix the issue. But is it enough to have a single core dev to maintain a platform?

In general, is Python 32-bit still popular on Windows? It seems like numpy provides win32 binary wheels for Python 3.11, but Pillow doesn’t.

Python Windows download page sadly still proposes the 32-bit flavor before 64-bit flavor in the list. Same in the download links of Python 3.11.5 release for example. I’m surprised that python.org does not provide any guidance to make a decision between the Windows 32-bit and Windows 64-bit choice.

It seems like Conda only offers 64-bit flavor on Windows.

On a fresh Python, if I type “python” in a terminal, Windows Store pops up and invites me to install Python 3.11. I click on [Get] and I get… Python 3.11.5 built in 64-bit mode: ah, we are good! :slight_smile:

While cibuildwheel supports Windows 32bit on Python 3.6 to Python 3.11, it doesn’t support Windows 32bit for PyPy 7.3. The reason is simple, PyPy no longer supports Windows 32-bit: it’s gone from the download page. They dropped Windows 32-bit support around PyPy v7.3.6.

Python 3.12.0 final is going to be shipped with Windows 32-bit installers. If we change something, it cannot happen before Python 3.13, Thomas Wouters is the Python 3.13 release manager (same for Python 3.12).

Summary:

  • python.org proposes Windows 32-bit and Windows 64-bit installer, the 32-bit flavor is listed first, and there is no guidance
  • Windows Store installs 64-bit binary
  • Conda only supports Windows 64-bit
  • GitHub Action Windows x86 (32 bit) is not mandatory (can fail, it doesn’t prevent to merge a PR)
  • numpy provides 64-bit binary, Pillow doesn’t
  • PyPy dropped Windows 64-bit

I’m not proposing to remove Windows 32-bit support in Python 3.13. Questions are more around:

  • Who is going to fix Windows 32-bit specific issues?
  • Should we still ship Windows 32-bit installers for Python 3.13?
  • Should we remove the GitHub Action Windows x86 job?

So, as written in the title: Consider downgrading Windows 32-bit from Tier-1 to Tier-2 or Tier-3? (in Python 3.13?)

Previous discussion in 2018 about python.org download page: why is not 64-bit installer the default download link for Windows?. In 2018, @steve.dower wrote:

Do Intel 32-bit CPU still exist in 2023? Is it possible to explicitly install Windows in 32-bit on a 64-bit CPU? What is the ratio of Windows users who cannot 64-bit Python?

Python test suite has a few tests specific to 32-bit. And the C code has obviously some code paths specific to 32-bit pointers (#if SIZEOF_VOID_P > 4).

Windows 32-bit is one of last 32-bit platforms that we still support on buildbots. The other one is ARM 32-bit CPU: ARM Raspbian buildbot worker: “Raspberry Pi 4 B running Raspbian (Bullseye 11.x).” Oh wait, the Cortex-A72 CPU is actually a 64-bit CPU! I suppose that @gpshead made the deliberate choice of installing Debian in 32-bit.

9 Likes
2

For what it’s worth, for pyca/cryptography we ship both 32- and 64-bit Windows wheels. Roughly 88% of the downloaded Windows wheels are for 64-bit.

We’d very much like to stop shipping 32-bit wheels (they’re a big burden on developer productivity because the CI for them is so slow), but for us the blocker is that we don’t know why people are using 32-bit!

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?

We hypothesize (without proof) that the last category is the most common, and CPython reducing its level of support for 32-bit Windows would hopefully encourage those users to migrate to a 64-bit Python.

10 Likes
3

Is it possible to have a working 32-bit CPU in 2023?

Is it possible to install Windows in 32-bit mode on purpose on 2023? Or was it possible before and people didn’t upgrade?

4

At least from my own personal experience, I’ve seen people install 32 bit python for no reason other than “I’ve clicked the first windows link I saw in Python’s downloads page”.

Also, there are people who download every possible wheel for the sake of having their own pypi replica in their internal networks

7 Likes
5

I don’t think Intel/AMD have sold 32-bit desktop/server CPUs for more than a decade. Whether people are running very old CPUs, I don’t know :slight_smile:

Windows 11 is the first version of Windows to be 64-bit only, Windows 10 was available in both 32- and 64-bit editions.

2 Likes
6

For the most recent Pillow 10.0 release (2023-07-01) we stopped distributing 32-bit wheels for all platforms.

But we kept compatibility and are still testing 32-bit (Debian, Windows). We had a couple of issues opened, but no real pushback.

The decision was partly based on download numbers for the previous 9.5.0 release. (It had very low numbers for Linux 32-bit wheels (0.01% - 0.09%).)

The Windows 32-bit wheels had a bigger proportion but still low (0.90% - 5.63%), with the smallest share for Python 3.10/3.11, and highest for 3.8.

More details: Dropping 32-bit packages - #20 by hugovk

This suggests there’s fewer 32-bit Windows users for newer Python versions.

3 Likes
7

FYI I had hard time to manage installing a Windows 11 VM, it has very strict hardware requirements:

Processor 1 gigahertz (GHz) or faster with 2 or more cores on a compatible 64-bit processor or System on a Chip (SoC).

Not only it should be 64-bit, but also “recent”. On my previous laptop, it didn’t want to run because of the too old CPU if I recall correctly. For example, I had to learn how to set up a TPM chip (in my VM) to please the Windows 11 installer.

Maybe older Windows versions can be run on 32-bit CPUs, I don’t know. And I don’t think that the lack of security fixes is really preventing users to continue using their old hardward on old Windows versions.

The question is more if we, Python developers, care about still providing best Tier-1 support for Windows 32-bit in Python 3.13.

8

The Python 3.11.5 page does list “Windows installer (64-bit)” as “Recommended”, but the Python Windows page doesn’t recommend any.

  • Can we recommend the 64-bit installer on both pages?
  • Can we list the 64-bit installer before the 32-bit installer on both pages?
6 Likes
9

Just a data point:

Even though most Windows installations are probably 64-bit by now, it is still rather common to run into 32-bit applications on Windows. If you want to interface to such a 32-bit application, you have to use a 32-bit Python version and 32-bit wheels, unless you can use some kind of IPC mechanism to bridge the gap.

E.g. say you have a 32-bit application using a database and you want to access the database using an ODBC driver from Python, then you have to use a 32-bit version of Python in order to access that database.

Things are getting better, since applications on Windows are slowly moving towards 64-bit per default, but using the number of Windows installations as a reference for how wide-spread 64-bit applications are on Windows is not a good metric.

11 Likes
10

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.

10 Likes
11

I think all WebAssembly builds are 32-bit.

2 Likes
12

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
13

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.
4 Likes
14

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.

2 Likes
15

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 | peps.python.org would need to be updated to mention this change for 3.13+.

1 Like
16

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.

3 Likes
17

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.

18

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”.

3 Likes
19

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.

5 Likes
20

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

1 Like