Python 3.15 delivers a native-by-default experience on Windows on Arm
14 Oktober 2026 om 19:00
Windows on Arm has been ready for Python development for some time. With Python 3.15, the broader ecosystem has matured significantly, with more package maintainers publishing native Arm64 wheels, allowing Windows on Arm to support mainstream Python development across a broad and growing set of workloads.
Windows on Arm is now a Tier 2 CPython platform, backed by continuous testing and CPython’s release-quality commitments. That readiness extends beyond the runtime. Widely used packages such as NumPy, SciPy, pandas, scikit-learn, Django, and FastAPI are available, while Jupyter, VS Code, Ruff, and pytest support everyday development workflows. GitHub-hosted Windows on Arm runners also let open-source maintainers build and test their projects natively.
This did not happen with a single release. Native Windows on Arm builds of CPython have been available for several versions. What changes with Python 3.15 is the maturity of the experience. Windows on Arm is now a regular CPython target; the native runtime is selected by default on Windows on Arm devices, and CPython’s Tier 2 requirements call for platform failures to be fixed or the responsible changes reverted. Package maintainers now have practical infrastructure for native Windows on Arm validation, and many widely used projects publish native Arm64 wheels. Windows on Arm is now a practical platform for many mainstream Python development scenarios. As of September 2026, a scan of the 1,000 most-downloaded PyPI projects shows about 94% of the projects’ latest releases published either a native Windows on Arm wheel or a platform-independent wheel. This measures published wheel availability, not end-to-end application compatibility. Anaconda’s main channel also includes more than 2,500 packages published for Windows on Arm.
Platform readiness does not mean every Python application is automatically ready for Windows on Arm. The runtime and a broad set of mainstream development workflows are established, but application readiness still depends on the complete dependency graph, particularly when packages rely on native extensions. Developers should confirm native Arm support for their dependencies during migration and testing.
Applications that still depend on x64 packages can continue to run through Windows emulation, providing a practical transition path while those dependencies add native Arm support.
pip, venv, virtualenv, setuptools, build, and modern tools such as uv are available on the platform, either as Arm native or platform-independent. Several widely used Rust-based packages publish native Windows on Arm wheels, including pydantic-core, Ruff, orjson, tokenizers, and other widely used projects. A platform-independent top-level package can still depend on a native extension, so applications should test their complete pinned dependency graph.
Scientific computing and notebooks. NumPy and SciPy now publish native Windows on Arm wheels, backed by native OpenBLAS and Fortran support. pandas, Polars, Matplotlib, scikit-learn, Pillow, h5py, statsmodels, and XGBoost have also shipped Arm64 wheels. Numba and llvmlite add native JIT compilation to the scientific and machine learning stack. These packages exercise complex compiled build systems and native numerical toolchains rather than simple platform-neutral Python code.
JupyterLab, Notebook, ipykernel, pyzmq, and psutil make the local notebook experience practical with platform-independent wheels. Developers can use browser notebooks or the Jupyter experience in VS Code with a native kernel.
Web, cloud, and database development. Django, Flask, FastAPI, Requests, and HTTPX publish platform-independent wheels compatible with Windows on Arm. Several cloud SDK packages like AWS Boto3, Azure Storage Blob, and Google Cloud Storage publish platform-independent wheels that can run under Windows on Arm subject to their dependencies. SQLAlchemy is platform-independent, while database support includes libpq packages in Anaconda main, Microsoft’s Arm64 ODBC Driver 18, and native Windows on Arm wheels for python-oracledb.
Developer tools and native builds. VS Code, Pylance, the Python and Jupyter extensions, and JetBrains PyCharm, IntelliJ, WebStorm, and Rider have support for Windows on Arm. Ruff, Black, mypy, pytest, and coverage are available. MSVC and LLVM support native compilation, while Rust with PyO3 and maturin supports the growing set of Rust-based extensions. CMake, Meson, Ninja, vcpkg, OpenSSL, SQLite, libffi, and other common foundations are available for maintainers building binary packages.
GitHub-hosted runners are especially useful for open-source projects because maintainers can add native Windows on Arm CI without operating their own runner infrastructure. A native runner turns Windows on Arm support into a change that can fit into an existing build matrix. It also allows maintainers to test Windows on Arm continuously rather than relying on a one-time build.
"Arm is working with industry partners including Microsoft and community organizers to expand access to native Arm infrastructure and improve upstream support," said Grant Likely, Fellow at CoreCollective and Senior Director at Arm. "Our goal is to make Arm a standard part of how developers build, test and ship software. With the latest Python release, developers can build and run Python natively on Windows on Arm, making it easier to bring their existing workflows to Arm."
"Developers thrive when their tools just work, which is why a strong and comprehensive Python ecosystem is so important for Snapdragon X Series platforms. Working closely with Microsoft, Anaconda, and ecosystem partners, we continue to advance native support across the Python stack, making it easier for developers to build, test, and deploy applications on Windows on Snapdragon. This further enables developers to take advantage of superior performance, power efficiency, and AI capabilities of Snapdragon powered Windows devices." says Milan Plavsich, VP, Engineering, Qualcomm Technologies, Inc.