Python no Windows on Arm: suporte nativo no Python 3.15

Por que o Python 3.15 é um marco para a arquitetura Arm

Os builds nativos do CPython para Windows on Arm não nasceram agora. Eles existem há várias versões, porém a experiência ainda exigia atenção redobrada do desenvolvedor.

Afinal, ter um interpretador funcionando nunca foi suficiente. Um ambiente de desenvolvimento útil depende de pacotes compilados, editores, ferramentas de build e infraestrutura de integração contínua.

Segundo o anúncio oficial no Windows Developer Blog, o que muda agora é a maturidade do conjunto. Em outras palavras, o Python no Windows on Arm virou um alvo regular do CPython, e não mais um caso especial.

Além disso, o runtime nativo passa a ser escolhido automaticamente nos dispositivos Arm. Dessa forma, o desenvolvedor não precisa mais lembrar de baixar o instalador certo.

Para quem trabalha com notebooks equipados com processadores Snapdragon X, essa mudança tem impacto direto. Afinal, o código passa a rodar sem a camada de emulação na maior parte dos cenários comuns.

O que significa o Tier 2 para o Python no Windows on Arm

O CPython organiza as plataformas suportadas em níveis, conforme a PEP 11. Cada nível define um compromisso diferente da equipe principal com aquela combinação de sistema e arquitetura.

Com o 3.15, o Python no Windows on Arm alcança o Tier 2. Na prática, isso exige integração contínua confiável e desenvolvedores do núcleo ativos cuidando da plataforma.

Como instalar o Python no Windows on Arm

A instalação ficou mais simples com o Python Install Manager 26.4. Nos dispositivos Arm, o gerenciador assume Arm64 como plataforma padrão.

Portanto, ao pedir o Python 3.15, você recebe o runtime nativo, exceto quando uma configuração ou uma tag de arquitetura explícita indica outra coisa.

# instala o Python 3.15 usando a arquitetura padrão do dispositivo
py install 3.15

# lista os runtimes instalados e suas arquiteturas
py list

# executa um script com a versão desejada
py -V:3.15 main.py

Se você ainda está montando o ambiente do zero, a documentação da Microsoft sobre como configurar o Python no Windows mostra o passo a passo com winget e VS Code.

import platform
import sys


def describe_runtime() -> dict:
    # coleta as informações básicas do interpretador em execução
    return {
        "version": platform.python_version(),
        "machine": platform.machine(),
        "compiler": platform.python_compiler(),
        "is_native_arm64": "ARM64" in sys.version,
    }


if __name__ == "__main__":
    info = describe_runtime()
    for key, value in info.items():
        print(f"{key}: {value}")

    if not info["is_native_arm64"]:
        print("Warning: this interpreter is not running as native ARM64.")

Pacotes e wheels para o Python no Windows on Arm

O runtime é só uma parte da história. Por isso, o anúncio dedica boa parte do texto aos pacotes que o Python no Windows on Arm consegue instalar a partir do PyPI.

Em setembro de 2026, uma varredura nos 1.000 projetos mais baixados do PyPI encontrou cerca de 94% com wheel nativo para Windows on Arm ou wheel independente de plataforma na versão mais recente.

Contudo, esse número mede disponibilidade de wheels, não compatibilidade completa da aplicação. Um pacote puro em Python ainda pode depender de uma extensão nativa mais abaixo na árvore.

As ferramentas de empacotamento já estão prontas. Por exemplo, pip, venv, virtualenv, setuptools, build e uv funcionam na plataforma, seja como binários nativos ou como pacotes independentes de arquitetura.

Vários projetos escritos em Rust também publicam wheels nativos, como pydantic-core, Ruff, orjson e tokenizers. Assim, grande parte das ferramentas modernas de validação e lint roda sem emulação.

Anaconda e conda no Python no Windows on Arm

Para quem trabalha com ciência de dados, o Anaconda costuma ser o ponto de entrada. Por isso, a novidade mais relevante é que o canal principal de produção já publica pacotes para o Python no Windows on Arm.

Hoje esse canal reúne mais de 2.500 pacotes para as versões 3.12 a 3.14. Entre eles estão NumPy, SciPy, pandas, XGBoost, cryptography, Flask, Django e conectores como psycopg e pyodbc.

O canal também inclui o PyTorch 2.14 em versões para CPU e CUDA, compilado com Clang e OpenBLAS para Arm. Além disso, o CUDA Toolkit 13.4.1 e builds do llama.cpp com CUDA já estão disponíveis.

Por outro lado, o conda-forge ainda está em fase experimental. O projeto criou um repositório para a plataforma e começou a migração pelas ferramentas de empacotamento e build.

Enquanto isso, a Anaconda trabalha em um instalador do Miniconda para Windows on Arm. Com isso, o caminho para usar conda nativamente tende a ficar tão simples quanto em x64.

Testando o Python no Windows on Arm com GitHub Actions

Grande parte desse avanço veio da disponibilidade de runners hospedados. O GitHub Actions oferece os runners windows-11-arm e windows-11-vs2026-arm para repositórios públicos e privados elegíveis.

Antes deles, testar o Python no Windows on Arm exigia hardware próprio ou emulação. Agora, basta adicionar uma entrada na matriz de build que já existe.

O próprio CPython usa esse runner nos seus jobs nativos. Dessa forma, mantenedores de pacotes contam com a mesma infraestrutura que valida o interpretador.

name: tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        os: [windows-latest, windows-11-arm, ubuntu-latest]
        python-version: ["3.14", "3.15"]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}

      # confirma a arquitetura do interpretador usado no job
      - name: Show runtime
        run: python -c "import platform; print(platform.machine())"

      - name: Install dependencies
        run: python -m pip install -r requirements.txt

      - name: Run tests
        run: python -m pytest

Nesse workflow, a entrada windows-11-arm roda a mesma suíte de testes de forma nativa. Então, falhas específicas da arquitetura aparecem antes do merge, e não depois da publicação.

  build-wheels:
    runs-on: windows-11-arm
    steps:
      - uses: actions/checkout@v4

      # gera os wheels nativos para Arm64
      - uses: pypa/cibuildwheel@v3
        env:
          CIBW_ARCHS_WINDOWS: ARM64

      - uses: actions/upload-artifact@v4
        with:
          name: wheels-windows-arm64
          path: ./wheelhouse/*.whl

Emulação x64 como caminho de transição

Nem toda aplicação vai migrar de uma vez. Por isso, o Windows continua executando aplicações x64 por meio da emulação.

Na prática, isso funciona como uma ponte até o Python no Windows on Arm nativo. Você mantém o projeto rodando enquanto as dependências que faltam ganham suporte nativo.

Contudo, vale lembrar que não dá para misturar arquiteturas no mesmo processo. Um interpretador nativo não carrega uma extensão x64, e o contrário também vale.

Assim, se uma única dependência crítica só existe em x64, todo o ambiente precisa rodar emulado. Nesse caso, o ideal é isolar esse ambiente e acompanhar o projeto da dependência.

Como migrar um projeto Python para Windows on Arm

A plataforma estar pronta não significa que toda aplicação esteja pronta. Afinal, a compatibilidade depende do grafo completo de dependências, principalmente quando há extensões nativas.

Por isso, a recomendação é validar as dependências durante a migração. Um roteiro simples ajuda a reduzir surpresas ao adotar o Python no Windows on Arm.

1. Instale o Python 3.15 nativo e confirme a arquitetura pelo banner.
2. Crie um ambiente virtual novo, sem reaproveitar ambientes x64.
3. Instale as dependências fixadas aceitando apenas wheels binários.
4. Rode a suíte de testes completa no ambiente nativo.
5. Registre as dependências que falharem e reporte nos repositórios correspondentes.

O terceiro passo merece atenção especial. Quando você força o uso de wheels, o pip falha rapidamente em vez de tentar compilar um pacote sem toolchain configurada.

# cria e ativa um ambiente virtual nativo
py -V:3.15 -m venv .venv
.venv\Scripts\activate

# instala somente a partir de wheels para expor lacunas de suporte
python -m pip install --only-binary=:all: -r requirements.txt

Depois disso, um script pequeno ajuda a mapear quais pacotes instalados trazem código nativo. Com essa lista em mãos, fica mais fácil priorizar os testes no Python no Windows on Arm.

from importlib.metadata import distributions


def find_native_packages() -> list[tuple[str, str]]:
    # percorre os pacotes instalados e lê as tags do arquivo WHEEL
    native = []
    for dist in distributions():
        wheel_file = dist.read_text("WHEEL") or ""
        tags = [
            line.split(":", 1)[1].strip()
            for line in wheel_file.splitlines()
            if line.startswith("Tag:")
        ]
        platform_tags = [tag for tag in tags if not tag.endswith("-any")]
        if platform_tags:
            native.append((dist.metadata["Name"], ", ".join(platform_tags)))
    return sorted(native)


if __name__ == "__main__":
    for name, tags in find_native_packages():
        print(f"{name}: {tags}")

O script lê o arquivo WHEEL de cada distribuição instalada e filtra as tags que terminam em -any. Assim, sobram apenas os pacotes com binários específicos de plataforma, como win_arm64.

Esse tipo de verificação é útil em qualquer projeto. Se você está começando a estruturar seus estudos, o catálogo de cursos do balta.io reúne trilhas de fundamentos que ajudam nesse caminho.

Inteligência artificial e aceleração local

O suporte a IA também avançou. O ONNX Runtime publica pacotes nativos para CPU, e o Windows ML suporta Arm64 com provedores de execução para CPU, GPU e NPU.

Em dispositivos Snapdragon compatíveis, o provedor QNN do ONNX Runtime consegue usar os backends de CPU, GPU e NPU da Qualcomm. Dessa forma, modelos locais executados a partir do Python no Windows on Arm aproveitam o hardware dedicado.

Além disso, builds do PyTorch e de componentes CUDA da NVIDIA para Windows on Arm já estão disponíveis para validação. Portanto, o terreno para treinar e executar modelos localmente está sendo preparado.

Lacunas que ainda existem no Python no Windows on Arm

Apesar do progresso, o ecossistema ainda não está completo. O próximo foco declarado é ampliar a cobertura de wheels nativos para PyArrow, gRPC, OpenCV e clientes de banco de dados.

Esses pacotes aparecem com frequência em pipelines de dados e microsserviços. Por isso, vale verificar se o seu projeto depende de algum deles antes de planejar a migração.

No lado do conda, a Anaconda planeja adicionar o CUDA Toolkit 13.4.2 e, em seguida, pacotes com CUDA habilitado. O llama.cpp e o PyTorch estão entre os primeiros alvos dessa etapa.

Enquanto essas lacunas não fecham, a emulação continua sendo uma alternativa válida. Ainda assim, vale acompanhar os repositórios e reportar problemas quando encontrar.

Conclusão

O Python 3.15 marca o momento em que o Python no Windows on Arm passa a ser tratado como uma plataforma de primeira linha. O status Tier 2, a seleção automática do runtime nativo e os runners do GitHub Actions sustentam essa mudança.

Ao mesmo tempo, o ecossistema acompanhou o runtime. Com cerca de 94% dos pacotes mais baixados disponíveis e o Anaconda publicando milhares de pacotes, os cenários mais comuns já funcionam sem emulação.

No entanto, cada projeto precisa validar o próprio grafo de dependências. Por fim, se você mantém uma biblioteca, adicionar o runner Arm à sua matriz é a contribuição mais simples e mais valiosa que pode fazer agora.

FAQ

O Python no Windows on Arm roda de forma nativa?

Sim. Os builds nativos existem há várias versões e, a partir do 3.15, o Python Install Manager seleciona o runtime Arm64 por padrão nesses dispositivos.

Como saber se meu interpretador é nativo?

Abra o interpretador e confira o banner. Um runtime nativo mostra 64 bit (ARM64), enquanto um runtime emulado mostra 64 bit (AMD64).

Todos os pacotes do PyPI funcionam em Windows on Arm?

Não todos. Cerca de 94% dos 1.000 projetos mais baixados publicam wheels compatíveis, mas pacotes como PyArrow, gRPC e OpenCV ainda têm lacunas.

Posso usar Anaconda em um dispositivo Arm?

Sim. O canal principal do Anaconda publica mais de 2.500 pacotes para Windows on Arm, enquanto o instalador do Miniconda nativo ainda está em desenvolvimento.

O que acontece com dependências que só existem em x64?

Elas continuam funcionando por meio da emulação do Windows. Nesse caso, todo o ambiente precisa rodar com um interpretador x64.