You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This will be updated when we decide to make the ARM64 build the default for ARM64 users. That's still pending on the ecosystem having packages available (which is getting close, but you can encourage the packages you use to start releasing Windows ARM64 wheels to help things along).
This will be updated when we decide to make the ARM64 build the default for ARM64 users. That's still pending on the ecosystem having packages available (which is getting close, but you can encourage the packages you use to start releasing Windows ARM64 wheels to help things along).
Just little note, I've opened this issue for working on the code to contribute and will happy to help with another parts (I'm new in this project)
If you want to make a start on this part so we can be prepared, we're probably going to need a new native function (probably in src\_native\misc.cpp) that returns whether the current machine is natively ARM64 or not. We can do it more efficiently and reliably than the platform module, and since we'll need to run it practically every time we get launched, we need it to be quick.
Once that function exists, the change in src\manage\commands.py (around line 450 right now) will be straightforward.
If you want to make a start on this part so we can be prepared, we're probably going to need a new native function (probably in src\_native\misc.cpp) that returns whether the current machine is natively ARM64 or not. We can do it more efficiently and reliably than the platform module, and since we'll need to run it practically every time we get launched, we need it to be quick.
Once that function exists, the change in src\manage\commands.py (around line 450 right now) will be straightforward.
I've added the preparing, and if you have ideas for improving, I'll happy to do it: #201
Thanks for the first PR, I've merged it so that it shows up in all test runs for a while. I'm expecting we'll do a beta release fairly soon, so that will give it some broader testing without (hopefully) affecting anyone's workflow.
If you'd like to make a PR with the rest of the change to choose the default platform, that would be great. I won't be able to merge it until we've decided officially to do it, but you can definitely start testing it.
If you want to go even further, making PyManager build natively for ARM64 is also worth trying (if you've got an ARM64 machine, anyway). I'm not sure we'll do it, or if we even need to, but it'll be worth seeing if it's worthwhile and how much trouble it'll cause. We can easily distribute platform-specific packages through the Store, but I'm not real keen to do it through the website... it's worth experimenting with, for sure.
I posted https://discuss.python.org/t/python-on-windows-arm64/104524 putting a date on switching the default - it's twelve months away, which seems a long time, but it aligns with the 3.15 release and will ensure that package developers can spend the beta/RC period also checking the new platform.
We will definitely release betas before then with the default flipped. But because we can only auto-update in a straight line (there's no "channels" here), once we do that we can't ship a regular release that unflips it, or all the beta testers get broken.
Anyone who wants to test early can of course set default_platform in their configuration file.
I'll take care of it myself, so this isn't an invitation for PRs, but the next release is going to be aligned with the Python 3.15 release, so we can flip this switch in the source code now so it's in the prereleases.
Activity
zooba commentedon Oct 16, 2025
This will be updated when we decide to make the ARM64 build the default for ARM64 users. That's still pending on the ecosystem having packages available (which is getting close, but you can encourage the packages you use to start releasing Windows ARM64 wheels to help things along).
Arlu commentedon Oct 16, 2025
Just little note, I've opened this issue for working on the code to contribute and will happy to help with another parts (I'm new in this project)
zooba commentedon Oct 16, 2025
If you want to make a start on this part so we can be prepared, we're probably going to need a new native function (probably in
src\_native\misc.cpp) that returns whether the current machine is natively ARM64 or not. We can do it more efficiently and reliably than theplatformmodule, and since we'll need to run it practically every time we get launched, we need it to be quick.Once that function exists, the change in
src\manage\commands.py(around line 450 right now) will be straightforward.Arlu commentedon Oct 16, 2025
I've added the preparing, and if you have ideas for improving, I'll happy to do it:
#201
zooba commentedon Oct 17, 2025
Thanks for the first PR, I've merged it so that it shows up in all test runs for a while. I'm expecting we'll do a beta release fairly soon, so that will give it some broader testing without (hopefully) affecting anyone's workflow.
If you'd like to make a PR with the rest of the change to choose the default platform, that would be great. I won't be able to merge it until we've decided officially to do it, but you can definitely start testing it.
If you want to go even further, making PyManager build natively for ARM64 is also worth trying (if you've got an ARM64 machine, anyway). I'm not sure we'll do it, or if we even need to, but it'll be worth seeing if it's worthwhile and how much trouble it'll cause. We can easily distribute platform-specific packages through the Store, but I'm not real keen to do it through the website... it's worth experimenting with, for sure.
zooba commentedon Oct 23, 2025
I posted https://discuss.python.org/t/python-on-windows-arm64/104524 putting a date on switching the default - it's twelve months away, which seems a long time, but it aligns with the 3.15 release and will ensure that package developers can spend the beta/RC period also checking the new platform.
We will definitely release betas before then with the default flipped. But because we can only auto-update in a straight line (there's no "channels" here), once we do that we can't ship a regular release that unflips it, or all the beta testers get broken.
Anyone who wants to test early can of course set
default_platformin their configuration file.zooba commentedon Jul 31, 2026
I'll take care of it myself, so this isn't an invitation for PRs, but the next release is going to be aligned with the Python 3.15 release, so we can flip this switch in the source code now so it's in the prereleases.