HPy - Python için geliştirilmiş C API

• HPy, Python'ı C ile genişletmek için yeni bir API'dir
• #include <Python.h> yerine #include <hpy.h> kullanılır

HPy'nin avantajları

• CPython'da sıfır overhead: HPy ile yazılan uzantılar "normal" uzantılarla aynı hızda çalışır
• Alternatif implementasyonlarda daha hızlı: PyPy, GraalPy vb. üzerinde daha hızlı çalışır
• Evrensel ikili: HPy Universal ABI ile derlenen uzantılar, değişiklik olmadan CPython, PyPy, GraalPython vb. üzerinde yüklenebilir
• Eski C-API ile karışık kullanım için geçiş yolu: Legacy C-API çağrıları ile HPy API çağrıları karıştırılabilir. Tüm kod taşındığında, tüm CPython sürümlerinde, PyPy veya GraalPy üzerinde çalışan evrensel bir ikili olarak derlenebilir
• Debug modu: Bellek sızıntıları, nesnelerin hatalı yaşam süreleri, API'nin yanlış kullanımı gibi durumlar kolayca tespit edilebilir
• Daha iyi API: Standart Python/C API'nin sınırlamalarını aşar; daha tutarlı, daha kaliteli uzantılar üretir ve hata oluşmasını zorlaştıracak şekilde tasarlanmıştır
• Evrimleşebilme: PEP 620'de iyi özetlendiği gibi, standart Python/C API çok fazla iç implementasyon ayrıntısını açığa çıkararak C API'nin evrimini zorlaştırır. HPy ise tüm iç implementasyon ayrıntılarını gizlediği için bu sorunu yaşamaz

Güncel durum

• HPy aktif olarak geliştirilmektedir. 0.9.0 en güncel alfa sürümdür, ancak yakında alfa aşamasından çıkması ve kararlı sürüme ulaşması hedeflenmektedir
• HPy ABI'nin artık yeterince kararlı olduğu ve yaklaşan sürümlerde geriye ve ileriye dönük ikili uyumluluk taahhüdünün yerine getirilebileceği düşünülmektedir
• API'nin artık önemli paketleri taşımak için yeterli kullanım senaryosunu kapsadığı düşünülmektedir (özellikle numpy portuna bakılabilir)
• Porting guide ve kapsamlı dokümantasyon da sağlanmaktadır (özellikle API referansı)
• Tasarım tartışmalarına ve yeni gereksinimlere her zaman açıktır

HPy uyumlu uzantılar

• ultrajson-hpy: HPy'ye taşınan ilk gerçek modül
• piconumpy: Adından anlaşılacağı gibi, özel türler tanımlayan minimal bir numpy benzeri modül
• numpy: İddialı hedeflerden biri, numpy'yi HPy'ye taşımak ve bu deneyimi API tasarımının nasıl daha iyi yapılacağını anlamak için kullanmak. Bu port, test paketini geçmeye çok yakın
• matplotlib: NumPy bağımlılığı da bulunduğu için evrensel moda geçiş henüz tamamen tamamlanmış değil. HPy, legacy C API işlevlerini çağırmaya devam edip test paketini başarıyla çalıştırabilmek için legacy uyumluluk API'si sunuyor
• kiwi-solver: Matplotlib bağımlılığı olarak evrensel moda tamamen taşındı

GN⁺ görüşü

• HPy, Python/C API'nin sınırlamalarını aşan ve daha iyi genişletilebilirlik ile taşınabilirlik sunan son derece umut verici bir projedir
• Özellikle PyPy ve GraalPy gibi alternatif Python implementasyonlarında performans artışı potansiyelinin yüksek olması dikkat çekicidir
• Legacy C API'den geçiş zor olabilir, ancak HPy kademeli bir geçiş yolu sunarak bu süreci çok daha yönetilebilir hale getirir
• HPy benimsenirken mevcut build sistemleri ve dağıtım pipeline'larıyla entegrasyon, upstream projelerin bunu kabul etmesi ve HPy'nin kendi olgunluk ile kararlılık düzeyi dikkate alınmalıdır
• HPy ile benzer hedeflere sahip diğer projeler arasında Cython ve Rust'ın PyO3'ü de bulunur. Bunlar, düşük seviyeli C API yerine daha yüksek seviyeli diller kullanmaları bakımından HPy'den ayrılır

[GN⁺]

Hacker News görüşleri

• C API ile çalışmanın en can sıkıcı kısmı derleme/bağlama bayraklarını ayarlamak. python3-config yalnızca OS düzeyinde çalışıyor ve pip ile kurulan paketlere erişmek için kullanışsız. python3 -m venv bu tür betikler üretmiyor; anaconda/miniconda da sorunlu. Her paket, sabit kodlanmış python3 -c "import sys: print..." çağrılarıyla derleme betiklerini kirletiyor. CPython'a python3 -m sysconfig --json bayrağını ekleyen bir PR açtım

• Python dilinin tek bir uygulamaya fazla odaklanması uzun vadeli başarısı için tehdit olabilir. Web sunucuları, komut satırı programları ve gömülü cihazların farklı gereksinimleri var. Bu proje Python'un C API'sini, uygulama ayrıntılarını açığa çıkarmayan bir şeyle değiştirmekte başarılı olursa, alternatif uygulamaları sürdürmek ve yeni teknolojileri denemek daha kolay olabilir

• Bu projenin sürümden bağımsız Python binding'leri sağlayıp sağlamadığını merak ediyorum. Şu anda her sürüm için binding'leri ayrı ayrı derliyoruz ve bu, CI/CD süresini çok tüketiyor

• HPy uzantıları ile Cython/pybind11 uygulamalarını performans ve geliştirme süresi açısından karşılaştıran benchmark'lar ilginç olurdu

• Bu projenin PyBind11 veya nanobind gibi kütüphanelerle nasıl örtüştüğü net değil. Bu kütüphaneleri aynı şekilde kullanmak için yeniden yazmak gerekecek gibi görünüyor

• Bugünlerde C ile yazılan yeni uzantıların sayısını merak ediyorum. Çoğunlukla Boost Python, pybind, PyO3 gibi şeyler olduğunu düşünüyordum

• CPython binding'lerini en düşük ek yükle uygulama hakkında sık sık paylaşım yapıyorum ve bazı öneri, soru ve endişeleri paylaşmak istiyorum. HPy projesinin açılış sayfası ile deponun README'si yeniden yapılandırılsa iyi olur. PyPy, GraalPython ve diğer Python runtime'ları için destek istatistikleri olsaydı daha ikna edici olurdu

• HPyContext gibi kapsüllenmiş bir context nesnesi kullanmak, çok iş parçacıklı Python geleceği veya karmaşık ortamlarda faydalı. Ama HPyContext CPython'un singleton'ına yönlendiriliyorsa, sorun çözülmüş olmuyor

• 2019 tarihli benchmark'lar CPython'un METH_FASTCALL çağrı kuralından bahsediyor ama karşılaştırmıyor. Performans önemliyse, string formatter kullanmadan tuple içinden doğrudan argümanları ayrıştırmak daha iyi olur

• Python'da, C header verip paylaşılan kütüphaneyi yükleyerek struct'ları kullanılabilir hale getiren ve fonksiyonları çağırabilen, luajit'in ffi'sine benzer basit bir şey olup olmadığını merak ediyorum

• Python'dan Go çağırmakla ilgileniyorum ve gopy, cgo için Python binding'leri üretiyor. HPy<->cgo daha az ek yüke sahip olabilir

• Bu iş 20 yıl önce tamamlanmış olsaydı Python ekosisteminin ne kadar farklı olacağını hayal edin