HPy - uma API C aprimorada para Python

• HPy é uma nova API para estender o Python com C
• Usa #include <hpy.h> em vez de #include <Python.h>

Vantagens do HPy

• Overhead zero no CPython: extensões escritas com HPy rodam na mesma velocidade que extensões "normais"
• Mais rápido em implementações alternativas: roda mais rapidamente em PyPy, GraalPy etc.
• Binário universal: extensões compiladas com a HPy Universal ABI podem ser carregadas sem modificações em CPython, PyPy, GraalPython etc.
• Caminho de migração para mistura com a C-API antiga: é possível misturar chamadas da C-API legada com chamadas da API HPy. Quando todo o código for migrado, ele poderá ser compilado como um binário universal que funciona em todas as versões do CPython, no PyPy ou no GraalPy
• Modo de depuração: permite identificar facilmente vazamentos de memória, tempo de vida incorreto de objetos, uso inadequado da API etc.
• API melhor: supera as limitações da API padrão Python/C, gera extensões mais consistentes e de melhor qualidade, e foi projetada para tornar bugs menos prováveis
• Capacidade de evolução: como resumido no PEP 620, a API padrão Python/C expõe muitos detalhes de implementação internos, o que dificulta a evolução da API C. O HPy esconde todos os detalhes internos de implementação e não sofre desse problema

Estado atual

• O HPy está em desenvolvimento ativo. A 0.9.0 é a versão alfa mais recente, mas o projeto deve sair em breve do estado alfa e está trabalhando para uma versão estável
• A equipe sente que a ABI do HPy agora está estável o suficiente para cumprir a promessa de compatibilidade binária retroativa e futura nas próximas versões
• Acreditam que a API agora cobre casos de uso suficientes para migrar pacotes importantes, especialmente vendo o port do numpy
• Também oferecem um guia de portabilidade e documentação extensa, especialmente a referência da API
• Estão sempre abertos a discussões de design e novos requisitos

Extensões compatíveis com HPy

• ultrajson-hpy: o primeiro módulo real portado para HPy
• piconumpy: como o nome sugere, um módulo mínimo semelhante ao numpy que define tipos personalizados
• numpy: um dos objetivos ambiciosos é portar o numpy para HPy e usar essa experiência para entender melhor como projetar a API. Esse port está prestes a passar na suíte de testes
• matplotlib: como também depende do NumPy, a migração para o modo universal ainda não foi concluída totalmente. O HPy fornece uma API de compatibilidade legada para que seja possível continuar chamando funções da C API antiga no HPy e executar a suíte de testes com sucesso
• kiwi-solver: uma dependência do Matplotlib totalmente portada para o modo universal

Opinião do GN⁺

• O HPy é um projeto muito promissor para superar as limitações da API Python/C e oferecer melhor extensibilidade e portabilidade
• É especialmente atraente o grande potencial de ganho de desempenho em implementações alternativas de Python, como PyPy e GraalPy
• Migrar a partir da C API legada pode ser difícil, mas o HPy oferece um caminho de migração gradual que torna esse processo muito mais administrável
• Ao adotar o HPy, é preciso considerar a integração com os sistemas de build e pipelines de distribuição existentes, a aceitação por parte dos projetos upstream e o grau de maturidade e estabilidade do próprio HPy
• Outros projetos com objetivos semelhantes aos do HPy incluem o Cython e o PyO3 do Rust. Eles diferem do HPy por usarem linguagens de nível mais alto em vez da API C de baixo nível

[GN⁺]

Comentários do Hacker News

• A parte mais incômoda de trabalhar com a API C é configurar as flags de compilação/linkedição. python3-config só funciona no nível do SO e é difícil de usar para acessar pacotes instalados via pip. python3 -m venv não gera esses scripts, e anaconda/miniconda também é um problema. Cada pacote acaba poluindo os scripts de build com chamadas hardcoded como python3 -c "import sys: print...". Abri um PR para adicionar a flag python3 -m sysconfig --json ao CPython

• O fato de a linguagem Python estar focada demais em uma única implementação pode ser uma ameaça ao sucesso no longo prazo. Servidores web, programas de linha de comando e dispositivos embarcados têm requisitos diferentes. Se este projeto conseguir substituir a API C do Python por algo que não exponha detalhes de implementação, pode ficar mais fácil manter implementações alternativas e experimentar novas tecnologias

• Fico me perguntando se este projeto fornece bindings Python independentes de versão. No momento, estamos compilando bindings separadamente para cada versão, e isso consome muito tempo de CI/CD

• Seria interessante ver benchmarks comparando extensões HPy com implementações em Cython/pybind11 em termos de desempenho e tempo de desenvolvimento

• Não está claro como este projeto se encaixa com bibliotecas como PyBind11 ou nanobind. Parece que seria necessário reescrever para usá-las da mesma forma

• Fico curioso sobre quantas extensões novas escritas em C existem hoje em dia. Eu achava que era mais Boost Python, pybind e PyO3

• Costumo postar com frequência sobre implementar bindings para CPython com o mínimo de overhead, e gostaria de compartilhar algumas recomendações, perguntas e preocupações. Seria bom reorganizar a landing page do projeto HPy e o README do repositório. Estatísticas de apoio para PyPy, GraalPython e outros runtimes Python tornariam a proposta mais convincente

• Usar um objeto de contexto encapsulado como HPyContext é útil para um futuro Python multithread ou ambientes complexos. Mas, se HPyContext for redirecionado para o singleton do CPython, isso não resolve o problema

• Os benchmarks de 2019 mencionam a convenção de chamada METH_FASTCALL do CPython, mas ela não é comparada. Se desempenho importa, é melhor fazer o parse dos argumentos diretamente da tupla sem usar formatador de string

• Fico me perguntando se existe algo simples em Python, parecido com o ffi do luajit, em que você fornece headers C, carrega uma biblioteca compartilhada e consegue usar structs e chamar funções

• Tenho interesse em chamar Go a partir de Python, e o gopy gera bindings Python para cgo. HPy<->cgo poderia ter menos overhead

• Imaginem como o ecossistema Python seria diferente se esse trabalho tivesse sido concluído 20 anos atrás