Python 3.15 kiest op Windows on Arm standaard de native Arm64-build

Op Windows-machines met een Arm-processor kiest Python vanaf versie 3.15 standaard de native Arm64-build in plaats van de x64-variant die onder emulatie draait. Microsoft beschrijft die omslag in een blogpost voor Windows-ontwikkelaars van 14 oktober. Python 3.15.0 zelf kwam op 9 oktober uit, meldt python.org.

Niet nieuw, maar nu de standaard

Native Windows-on-Arm-builds van CPython bestaan al een paar versies. Wat met 3.15 verandert, is dat het de standaardkeuze wordt. Met Python Install Manager 26.4 kiezen Windows-on-Arm-apparaten standaard het Arm64-platform: wie om Python 3.15 vraagt, krijgt de native runtime, tenzij de configuratie of een expliciete architectuurtag iets anders voorschrijft. Python 3.15 levert daarnaast een volledige set Windows-on-Arm-componentpakketten naast de x64-pakketten.

Welke variant je daadwerkelijk draait, lees je af aan de startbanner van de interpreter. Een native build meldt 64-bit (ARM64) in de compilerinformatie, een geëmuleerde x64-build meldt 64-bit (AMD64).

Tier 2 in PEP 11

Achter die standaardkeuze zit een formele status. Windows on Arm is in PEP 11 een Tier 2-platform, wat betekent dat er betrouwbare continuous integration en actieve core-ontwikkelaars voor zijn, en dat wijzigingen die het platform breken ofwel gerepareerd ofwel teruggedraaid moeten worden. De testresultaten voor Windows on Arm wegen volgens Microsoft mee in het releaseproces van CPython; de jobs lopen in de normale Windows-buildmatrix, inclusief de free-threaded configuratie.

De pakketten zijn grotendeels mee

Een runtime alleen is niet genoeg; het staat of valt bij de packages met gecompileerde extensies. Microsoft noemt een scan van de duizend meest gedownloade PyPI-projecten in september 2026: van ongeveer 94 procent publiceerde de nieuwste release óf een native Windows-on-Arm-wheel óf een platformonafhankelijke wheel. Microsoft tekent daar zelf bij aan dat dit alleen de beschikbaarheid van wheels meet, niet of een complete applicatie werkt. Het main-channel van Anaconda heeft volgens dezelfde post meer dan 2.500 pakketten voor Windows on Arm.

Concreet genoemd: NumPy en SciPy publiceren native wheels, met native OpenBLAS en Fortran-ondersteuning eronder. Pandas, Polars, Matplotlib, scikit-learn, Pillow, h5py, statsmodels en XGBoost leveren Arm64-wheels, en Numba en llvmlite brengen native JIT-compilatie mee. Bij de in Rust geschreven pakketten gaat het onder meer om pydantic-core, Ruff, orjson en tokenizers. Pip, venv, virtualenv, setuptools, build en uv zijn beschikbaar, en GitHub biedt Windows-on-Arm-runners waarop open source-projecten native kunnen bouwen en testen.

Wat het niet betekent

Microsoft is opvallend expliciet over de grens van deze aankondiging: dat het platform klaar is, betekent niet dat elke Python-applicatie klaar is. Dat hangt af van de volledige dependency-graph, en vooral van pakketten die op native extensies leunen. Het advies is om bij een migratie de hele vastgepinde set dependencies te testen op native Arm-ondersteuning.

Voor wie daar nog niet uit komt, blijft de oude route open. Applicaties die van x64-pakketten afhankelijk zijn, kunnen onder Windows-emulatie blijven draaien zolang die dependencies geen native Arm-versie hebben. De winst van native draaien zit erin dat interpreter en gecompileerde dependencies op dezelfde Arm64-architectuur zitten, zonder emulatielaag ertussen.