Python 3.15 rende Windows on Arm finalmente nativo per gli sviluppatori

📌 In Sintesi

• Python 3.15 seleziona automaticamente il runtime Arm64 sui dispositivi Windows on Arm attraverso Python Install Manager 26.4.
• Windows on Arm è ora piattaforma CPython Tier 2 e circa il 94% dei 1.000 progetti PyPI più scaricati offre wheel compatibili.
• GitHub Actions, Anaconda, NumPy, SciPy, PyTorch e toolchain native riducono la dipendenza dall’emulazione x64 per lo sviluppo professionale.

Python 3.15 trasforma Windows on Arm da piattaforma compatibile a piattaforma nativa per una parte sempre più ampia dello sviluppo software. Microsoft non annuncia semplicemente un nuovo interprete Arm64: il cambiamento riguarda runtime, package ecosystem, compilazione, CI e data science. Con Python Install Manager 26.4, un dispositivo Windows on Arm che richiede Python 3.15 riceve automaticamente il runtime Arm64, mentre CPython considera ormai la piattaforma Tier 2. La vera soglia è però nell’ecosistema: secondo Microsoft, a settembre 2026 circa il 94% dei 1.000 progetti più scaricati da PyPI distribuiva già una wheel Arm64 nativa oppure una wheel indipendente dall’architettura.

Python 3.15 sceglie Arm64 senza chiedere più allo sviluppatore di pensarci

Nel Windows Developer Blog dedicato a Python 3.15 su Windows on Arm, Microsoft individua il cambiamento principale nell’esperienza predefinita. Le build native di CPython per Windows Arm esistevano già, ma con Python Install Manager 26.4 l’architettura Arm64 diventa la scelta automatica sui dispositivi compatibili, salvo configurazioni o tag espliciti differenti. Python 3.15 distribuisce inoltre il set completo dei componenti Windows Arm insieme alle versioni x64 e CPython esegue regolarmente sulla piattaforma sia i test dell’interprete tradizionale sia quelli della configurazione free-threaded. L’emulazione x64 resta disponibile per le applicazioni ancora dipendenti da componenti non portati, ma smette progressivamente di rappresentare il percorso normale. È il passaggio successivo rispetto alla maturazione già osservata quando Windows on Arm aveva superato 7.000 applicazioni e giochi verificati: Microsoft sta spostando la stessa logica dal software consumer alla toolchain degli sviluppatori.

Leggi anche: Microsoft punta su ARM mentre EndeavourOS lo dismette perché senza manutenzione

Il 94% dei principali progetti PyPI riduce il vero collo di bottiglia di Windows ARM

Il problema storico di Python su ARM non è mai stato soltanto l’interprete. Le difficoltà arrivano quando un progetto dipende da estensioni native compilate per x86-64. Microsoft dichiara che circa il 94% dei 1.000 progetti PyPI più scaricati offre ormai, nell’ultima release disponibile, una wheel Windows Arm nativa o una wheel Python indipendente dalla piattaforma. Il dato non equivale alla compatibilità garantita di ogni applicazione, perché una dipendenza apparentemente platform-independent può richiamare a sua volta componenti nativi, ma il salto è rilevante.

NumPy, SciPy, pandas, Polars, Matplotlib, scikit-learn, Pillow, h5py, statsmodels e XGBoost hanno build Arm64; Numba e llvmlite portano anche il JIT nativo, mentre pydantic-core, Ruff, orjson e tokenizers mostrano che persino l’ecosistema Rust sta distribuendo binari Windows Arm. È qui che la battaglia storica tra ARM e x86 sul PC cambia natura: la compatibilità non dipende più soltanto dalla capacità del sistema operativo di emulare il vecchio software, ma dalla disponibilità diretta delle dipendenze nella nuova architettura.

Anaconda porta data science, PyTorch e CUDA dentro lo stack Arm64

Anaconda rappresenta il passaggio dalla compatibilità generale agli ambienti scientifici e AI. Il canale principale comprende oltre 2.500 pacchetti Windows on Arm per Python 3.12, 3.13 e 3.14, tra cui NumPy, SciPy, pandas, XGBoost, llama.cpp, cryptography, Flask, Django e componenti PostgreSQL e ODBC. Microsoft segnala inoltre pacchetti PyTorch 2.14 CPU e CUDA, CUDA Toolkit 13.4.1 e build CUDA di llama.cpp disponibili attraverso Anaconda, mentre conda-forge ha avviato una migrazione sperimentale verso Windows Arm.

Restano ancora dei buchi: Microsoft cita esplicitamente PyArrow, gRPC, OpenCV e alcuni database client tra le aree da completare. La piattaforma non è quindi universalmente nativa, ma la differenza rispetto alle prime generazioni Snapdragon è sostanziale. Il percorso accompagna quello hardware già visibile con Snapdragon C e l’espansione di Windows on ARM verso notebook più economici: l’architettura smette di dipendere esclusivamente da poche applicazioni adattate e acquisisce una base utilizzabile per sviluppo, analisi dati e AI.

GitHub Actions elimina la necessità di possedere un PC ARM per compilare su ARM

Un ecosistema nativo ha bisogno anche di build e test nativi. GitHub Actions mette a disposizione i runner windows-11-arm e windows-11-vs2026-arm, che consentono ai maintainer di compilare wheel ed eseguire test suite direttamente su Windows Arm senza gestire hardware self-hosted. CPython utilizza la stessa infrastruttura per i propri job Arm64.

È un elemento meno visibile rispetto all’arrivo di una nuova CPU, ma strategicamente più importante: un progetto può aggiungere Windows Arm alla propria matrice CI allo stesso modo di Windows x64, Linux o macOS e intercettare regressioni specifiche dell’architettura prima della pubblicazione. MSVC, LLVM, Rust, PyO3, maturin, CMake, Meson, Ninja, vcpkg, OpenSSL e SQLite completano una toolchain che rende possibile compilare realmente sulla piattaforma invece di limitarsi a eseguire software emulato. La strategia si collega alla trasformazione più ampia del developer environment Microsoft tra Windows 365, workstation locali e ambienti pronti al coding.

Continua con:

ARM accelera su due fronti: Armbian 26.8 rinnova Linux e Windows supera 7.000 app

Snapdragon C porta Windows on ARM nei notebook economici

Windows on Arm ora deve dimostrare che “nativo” significa davvero trasparente

Python 3.15 non elimina tutte le differenze tra ARM64 e x64, ma sposta il punto nel quale lo sviluppatore è costretto a pensarci. Se interprete, ambiente virtuale, editor, notebook, compilatore e gran parte delle dipendenze arrivano già in versione nativa, l’architettura sottostante smette progressivamente di essere una configurazione speciale. Restano applicazioni con dependency graph complessi, estensioni native non portate e workload per i quali l’emulazione continuerà a essere necessaria. Ma è proprio questa la soglia che Microsoft cercava di raggiungere: non dimostrare che Python può funzionare su ARM, cosa vera da tempo, ma fare in modo che uno sviluppatore possa installarlo e iniziare a lavorare senza dover costruire manualmente un percorso alternativo. Windows on Arm sta quindi passando dalla fase della compatibilità alla fase più difficile: diventare sufficientemente ordinario da non richiedere più una spiegazione ogni volta che viene usato.