Python on Windows ARM64

Core Development
1

Those who read all the way through release pages will have noticed that we’ve had “experimental” releases for Windows ARM64 platforms. These have been stable since about 3.10, but it’s taken a while for the ecosystem to catch up.

During that time, we didn’t want “regular” users using it, as they had an almost certain likelihood of failing to install packages due to lack of wheels.[1] The “experimental” label was intended to dissuade these users, while still allowing early adopters and (it was hoped) package developers to get prepared.

With GitHub Actions adding ARM64 images earlier this year, and a multi-year effort by a number of people (many supported by Microsoft specifically to help projects add support), it now appears that as many projects who are willing to support the platform already do, and we aren’t likely to be any more prepared for regular users to start using the ARM64 build on their platform.

So this post is an announcement of intent to make the Windows ARM64 releases the default for Windows ARM64 users at the time when 3.15 is released. So around October 2026, our recommendation (and the behaviour of our install manager) will be to install our ARM64 binaries on Windows ARM64 machines. The current recommendation/behaviour is to always install the AMD64 binaries and let them be emulated.

Broadly speaking, packages that have released wheels for Windows ARM64 are supporting at least 3.14, and often back to 3.11 (or 3.9, which is entirely unnecessary, but go ahead). Combined with the fact that it’s easier for tools such as the Python install manager and uv to change the default for all versions at once, our plan is to do just that.

Also worth noting that this does not change the support tier (PEP 11) of the Windows ARM64 platform, where it remains Tier 3.[2] That does put us in an awkward position if there’s a platform-specific issue that doesn’t affect other Windows architectures, since an ARM64-specific blocker won’t delay the entire release, but I think we’re fine to deal with that if/when it occurs. We’ve already been releasing for the last few years without issue.

This post is the place to capture any feedback, since we can very easily change our minds if good reasons are raised. With twelve months notice, hopefully it won’t be a big surprise when the change occurs.[3]

  1. Intel emulation on Windows ARM64 is very good, but while it’s continuing to be improved, native binaries are of course more efficient and better integrated with the OS. ↩︎

  2. Until a second core dev volunteers to offer support, and we add the handful of lines to the GitHub Actions PR configuration to build and test it. ↩︎

  3. Anecdotally, I’ve heard plenty of surprise that we haven’t changed it earlier (and a few demands that I get it changed immediately, which obviously I’ve resisted for the sake of our user base). ↩︎

20 Likes
2

Just out of curiosity - is there a summary of popular packages that support ARM64? It sounds like some static analysis has been done already. I first thought of something like the Python 3.14 readiness page https://pyreadiness.org/3.14/, but that just covers releases not platforms.

1 Like
3

I don’t know that there’s any particular resource that’s totally reliable right now, but there is http://www.winarm64wheels.com/ (which unfortunately only checks packages with native binaries, and assumes that pure Python packages are fine, which they may not be) and @cgohlke has GitHub - cgohlke/win_arm64-wheels: Experimental wheels for Python for Windows on ARM64., which at least proves that packages can be built for ARM64 even if the upstream projects aren’t doing their own releases.

You can also look at the download files on PyPI for wheels with win_arm64 as the platform tag, or do pip download --platform win_arm64 --only-binary :all: <package> on any platform to see if there are releases (you likely also need --pre right now).

4 Likes
4

The one thing I’d say about Windows ARM64 is that it’s a bit of an ordeal for maintainers to debug if you do have problems (I realize the same could be said for pretty much any platform that you don’t have hardware for, but right now Windows ARM64 is both niche and expensive). I don’t have any sensible suggestions for what what to do about that; just that Microsoft should probably be aware that for a lot of projects it’s only semi-supported.

(Edited addition: this is the opinion of someone who spent longer than he wanted printf debugging an MSVC compiler bug on GitHub Actions and who hopes not to repeat the exercise)

That’s not really a criticism of your timeline, which sounds like the right thing to do.

4 Likes
5

FWIW, the VMs on Azure I can see on my personal subscription[1] are about $20 USD/month cheaper than the equivalent Intel VMs. I haven’t checked out laptops recently, but last time I did they didn’t seem outrageous (i.e. they were cheaper than the Mac laptops you all have that can also run WinARM64 in Parallels :wink: )

  1. If you’re looking, the VM names are like D2ps_v6 where the p indicates ARM - so D2s_v6 is the equivalent Intel and I think D2as_v6 (if it exists) indicates an AMD processor. But don’t quote me on anything other than the p. ↩︎

6

If you have an arm64 macOS, UTM virtualises Windows ARM64 pretty well.

2 Likes
7

Thanks both for the suggestions on virtualization. To their credit, Microsoft is usually pretty good at making sure that Windows can be run in as many places as possible (unlike Apple, for example)

8

@steve.dower thanks for sharing and I really welcome the proposal. This is indeed a step in the right direction.

I’m wondering though why not the bump on PEP 11 to a Tier-2 at least. I think we should make an effort to find one o more folks who are willing to take care of this platform if something goes wrong.

Otherwise this is a mixed message to the end user: the default version on Windows on Arm is the native one but if there are problems with it, we might not include the fix in the next release.

I appreciate that the availability of hardware is somehow limited, but, as others said, it can be virtualised on MacOS (UTM, Parallels). I hope someone in the core team who is also an expert on Windows, can do that :slight_smile:

1 Like
9

I see you’re a core dev now, and I don’t think you were when we last discussed it… are you volunteering? :slight_smile:

1 Like
10

But unfortunately I’m not a Windows/MSVC expert :frowning: Ultimately dealing with a generic CPython Windows problem it should be the same for both x86_64 and Arm64 unless you go down deep the code generation.

This means if there is a CPython Windows issue, is we fix it on a platform, it should go also for the other platform. I mean, this is true for Linux as well. Of course there are differences between the two platforms, but the characterisation of the issues is usually at higher level.

If I got this completely wrong, it just shows that I don’t have much Windows expertise unfortunately.

1 Like
11

Yeah, it’s true (probably more true for Windows than Linux), but that doesn’t work for PEP 11. What’s needed more than anything else is someone with access to the hardware, so they can bisect a break and find the commit, and enough permissions to do a revert.

But yeah, it would be ideal to be able to bump up the PEP 11 tier.

1 Like
12

I guess at some point we need to socialise the idea within the core team to find another volunteer with Windows on Arm access. Do you think you require physical HW or virtualisation (Parallels, UTM) is enough?

1 Like
13

I think virtualisation is fine.

1 Like
14

I think a Windows on Arm virtual machine in Azure will do as well.