C API and ABI Stability

A menos que documentado de outra forma, a API C do Python é coberta pela Política de Compatibilidade com versões anteriores, PEP 387. A maioria das alterações são compatíveis com a fonte (normalmente adicionando apenas uma nova API). A alteração ou remoção da API existente só é feita após um período de descontinuação ou para corrigir problemas sérios.

A Interface Binária de Aplicação (ABI) do CPython é compatível para frente e para trás através de uma versão menor (se elas forem compiladas da mesma maneira; veja Considerações da plataforma abaixo). Portanto, o código compilado para Python 3.10.0 funcionará em 3.10.8 e vice-versa, mas precisará ser compilado separadamente para 3.9.x e 3.11.x.

Existem dois níveis de API C com diferentes expectativas de estabilidade:

  • API Instável (“Unstable API”), pode mudar em versões menores sem período de depreciação. É marcado pelo prefixo PyUnstable nos nomes.

  • API Limitada (“Limited API”), é compatível em várias versões menores. Quando Py_LIMITED_API é definido, apenas este subconjunto é exposto de Python.h.

Elas são discutidas em mais detalhes abaixo.

Nomes prefixados por um sublinhado, como _Py_InternalState, são APIs privadas que podem ser alteradas sem aviso prévio, mesmo em lançamentos de correção. Se você precisa usar essa API, considere entrar em contato com os desenvolvedores do CPython para discutir a adição de uma API pública para o seu caso de uso.

API C Instável

Qualquer API nomeada com o prefixo “PyUnstable” expõe detalhes de implementação do CPython e pode mudar em cada versão menor (por exemplo, de 3.9 para 3.10) sem nenhum aviso de depreciação. No entanto, não mudará em uma versão de correção de bugs (por exemplo, de 3.10.0 para 3.10.1).

É geralmente destinado a ferramentas especializadas de baixo nível, como depuradores.

Projetos que utilizam esta API são esperados para seguir o desenvolvimento do CPython e dedicar esforço extra para se ajustar às mudanças.

Interface Binária de Aplicação Estável

Para simplificar, este documento fala sobre extensões, mas a API Limitada e a ABI Estável funcionam da mesma maneira para todos os usos da API – por exemplo, embutir o Python.

API C Limitada

Python 3.2 introduziu a API Limitada, um subconjunto da API C do Python. Extensões que apenas usam o Limited API podem ser compiladas uma vez e ser carregadas em várias versões do Python. Os conteúdos da API Limitada estão listados abaixo.

Py_LIMITED_API

Defina essa macro antes de incluir Python.h para optar por usar apenas a API Limitada e selecionar a versão da API Limitada.

Defina Py_LIMITED_API com o valor de PY_VERSION_HEX correspondente à versão mais baixa do Python que sua extensão suporta. A extensão terá compatibilidade com a ABI de todas as versões do Python 3 a partir daquela especificada, e poderá usar a API Limitada introduzida até aquela versão.

Em vez de usar diretamente a macro PY_VERSION_HEX, codifique uma versão menor mínima (por exemplo, 0x030A0000 para o Python 3.10) para garantir estabilidade ao compilar com versões futuras do Python.

Você também pode definir Py_LIMITED_API como 3. Isso funciona da mesma forma que 0x03020000 (Python 3.2, a versão que introduziu a API Limitada).

ABI Estável

Para habilitar isso, o Python fornece uma ABI Estável: um conjunto de símbolos que permanecerão compatíveis com ABI em todas as versões do Python 3.x.

Nota

O ABI Estável previne problemas de ABI, como erros de ligador devido a símbolos ausentes ou corrupção de dados devido a alterações em layouts de estrutura ou assinaturas de função. No entanto, outras alterações no Python podem alterar o comportamento das extensões. Veja a Política de Retrocompatibilidade do Python (PEP 387) para detalhes.

A ABI Estável contém símbolos expostos na API Limitada, mas também outros – por exemplo, funções necessárias para suportar versões mais antigas da API Limitada.

No Windows, as extensões que usam a ABI Estável devem ser vinculadas a python3.dll em vez de uma biblioteca específica de versão, como python39.dll.

Em algumas plataformas, o Python procurará e carregará arquivos de biblioteca compartilhada com o nome marcado como abi3 (por exemplo, meumódulo.abi3.so). Ele não verifica se essas extensões estão em conformidade com uma ABI Estável. O usuário (ou suas ferramentas de empacotamento) precisa garantir que, por exemplo, as extensões construídas com a API Limitada 3.10+ não sejam instaladas em versões mais baixas do Python.

Todas as funções na ABI estável estão presentes como funções na biblioteca compartilhada do Python, não apenas como macros. Isso as torna utilizáveis em linguagens que não utilizam o pré-processador C.

Escopo e Desempenho da API Limitada

O objetivo da API Limitada é permitir tudo o que é possível com a API C completa, mas possivelmente com uma penalidade de desempenho.

Por exemplo, enquanto PyList_GetItem() está disponível, sua variante de macro “insegura” PyList_GET_ITEM() não está. A macro pode ser mais rápida porque pode depender de detalhes de implementação específicos da versão do objeto da lista.

Sem a definição de Py_LIMITED_API, algumas funções da API C são colocadas “inline” ou substituídas por macros. Definir Py_LIMITED_API desativa esse inline, permitindo estabilidade à medida que as estruturas de dados do Python são aprimoradas, mas possivelmente reduzindo o desempenho.

Ao deixar de fora a definição Py_LIMITED_API, é possível compilar uma extensão da API Limitada com uma ABI específica da versão. Isso pode melhorar o desempenho para essa versão do Python, mas limitará a compatibilidade. Compilar com Py_LIMITED_API vai produzir uma extensão que pode ser distribuída quando uma específica da versão não estiver disponível – por exemplo, para pré-lançamentos de uma próxima versão do Python.

Limitações da API Limitada

Observe que compilar com Py_LIMITED_API não é uma garantia completa de que o código esteja em conformidade com a API Limitada ou com a ABI Estável. Py_LIMITED_API abrange apenas definições, mas uma API também inclui outras questões, como semântica esperada.

Uma questão que Py_LIMITED_API não protege é a chamada de uma função com argumentos inválidos em uma versão inferior do Python. Por exemplo, considere uma função que começa a aceitar NULL como argumento. No Python 3.9, NULL agora seleciona um comportamento padrão, mas no Python 3.8, o argumento será usado diretamente, causando uma referência NULL e uma falha. Um argumento similar funciona para campos de estruturas.

Outra questão é que alguns campos de estrutura não estão atualmente ocultos quando Py_LIMITED_API é definido, mesmo que eles façam parte da API Limitada.

Por esses motivos, recomendamos testar uma extensão com todas as versões menores do Python que ela oferece suporte e, preferencialmente, construir com a versão mais baixa dessas.

Também recomendamos revisar a documentação de todas as APIs utilizadas para verificar se ela faz parte explicitamente da API Limitada. Mesmo com a definição de Py_LIMITED_API, algumas declarações privadas são expostas por razões técnicas (ou até mesmo acidentalmente, como bugs).

Também observe que a API Limitada não é necessariamente estável: compilar com Py_LIMITED_API com Python 3.8 significa que a extensão será executada com Python 3.12, mas não necessariamente será compilada com Python 3.12. Em particular, partes da API Limitada podem ser descontinuadas e removidas, desde que a ABI Estável permaneça estável.

Considerações da plataforma

A estabilidade da ABI depende não apenas do Python, mas também do compilador utilizado, das bibliotecas de nível inferior e das opções do compilador. Para os fins da ABI Estável, esses detalhes definem uma “plataforma”. Geralmente, eles dependem do tipo de sistema operacional e da arquitetura do processador.

É responsabilidade de cada distribuidor particular do Python garantir que todas as versões do Python em uma plataforma específica sejam construídas de forma a não quebrar a ABI estável. Isso é válido para as versões do Windows e macOS disponibilizadas pela python.org e por muitos distribuidores terceiros.

ABI Checking

Adicionado na versão 3.15.0a0 (unreleased).

Python includes a rudimentary check for ABI compatibility.

This check is not comprehensive. It only guards against common cases of incompatible modules being installed for the wrong interpreter. It also does not take platform incompatibilities into account. It can only be done after an extension is successfully loaded.

Despite these limitations, it is recommended that extension modules use this mechanism, so that detectable incompatibilities raise exceptions rather than crash.

Most modules can use this check via the Py_mod_abi slot and the PyABIInfo_VAR macro, for example like this:

PyABIInfo_VAR(abi_info);

static PyModuleDef_Slot mymodule_slots[] = {
   {Py_mod_abi, &abi_info},
   ...
};

The full API is described below for advanced use cases.

int PyABIInfo_Check(PyABIInfo *info, const char *module_name)
Parte da ABI Estável desde a versão 3.15.

Verify that the given info is compatible with the currently running interpreter.

Return 0 on success. On failure, raise an exception and return -1.

If the ABI is incompatible, the raised exception will be ImportError.

The module_name argument can be NULL, or point to a NUL-terminated UTF-8-encoded string used for error messages.

Note that if info describes the ABI that the current code uses (as defined by PyABIInfo_VAR, for example), using any other Python C API may lead to crashes. In particular, it is not safe to examine the raised exception.

Adicionado na versão 3.15.0a0 (unreleased).

PyABIInfo_VAR(NAME)
Parte da ABI Estável desde a versão 3.15.

Define a static PyABIInfo variable with the given NAME that describes the ABI that the current code will use. This macro expands to:

static PyABIInfo NAME = {
    1, 0,
    PyABIInfo_DEFAULT_FLAGS,
    PY_VERSION_HEX,
    PyABIInfo_DEFAULT_ABI_VERSION
}

Adicionado na versão 3.15.0a0 (unreleased).

type PyABIInfo
Parte da ABI Estável (incluindo todos os membros) desde a versão 3.15.
uint8_t abiinfo_major_version

The major version of PyABIInfo. Can be set to:

  • 0 to skip all checking, or

  • 1 to specify this version of PyABIInfo.

uint8_t abiinfo_minor_version

The major version of PyABIInfo. Must be set to 0; larger values are reserved for backwards-compatible future versions of PyABIInfo.

uint16_t flags

This field is usually set to the following macro:

PyABIInfo_DEFAULT_FLAGS

Default flags, based on current values of macros such as Py_LIMITED_API and Py_GIL_DISABLED.

Alternately, the field can be set to to the following flags, combined by bitwise OR. Unused bits must be set to zero.

ABI variant – one of:

PyABIInfo_STABLE

Specifies that the stable ABI is used.

PyABIInfo_INTERNAL

Specifies ABI specific to a particular build of CPython. Internal use only.

Free-threading compatibility – one of:

PyABIInfo_FREETHREADED

Specifies ABI compatible with free-threading builds of CPython. (That is, ones compiled with --disable-gil; with t in sys.abiflags)

PyABIInfo_GIL

Specifies ABI compatible with non-free-threading builds of CPython (ones compiled without --disable-gil).

uint32_t build_version

The version of the Python headers used to build the code, in the format used by PY_VERSION_HEX.

This can be set to 0 to skip any checks related to this field. This option is meant mainly for projects that do not use the CPython headers directly, and do not emulate a specific version of them.

uint32_t abi_version

The ABI version.

For the Stable ABI, this field should be the value of Py_LIMITED_API (except if Py_LIMITED_API is 3; use Py_PACK_VERSION(3, 2) in that case).

Otherwise, it should be set to PY_VERSION_HEX.

It can also be set to 0 to skip any checks related to this field.

PyABIInfo_DEFAULT_ABI_VERSION

The value that should be used for this field, based on current values of macros such as Py_LIMITED_API, PY_VERSION_HEX and Py_GIL_DISABLED.

Adicionado na versão 3.15.0a0 (unreleased).

Conteúdo da API Limitada

Atualmente, a API Limitada inclui os seguintes itens: