HPy - Python के लिए बेहतर C API

• HPy, C के ज़रिए Python को extend करने के लिए एक नया API है
• #include <Python.h> की जगह #include <hpy.h> का उपयोग करें

HPy के फायदे

• CPython में zero overhead: HPy से लिखे गए extension, "सामान्य" extension जितनी ही गति से चलते हैं
• वैकल्पिक implementations में अधिक तेज़: PyPy, GraalPy आदि में अधिक तेज़ी से चलते हैं
• Universal binary: HPy Universal ABI से बने extension, CPython, PyPy, GraalPython आदि में बिना किसी बदलाव के लोड किए जा सकते हैं
• पुराने C-API के साथ मिश्रण के लिए migration path: legacy C-API calls और HPy API calls को मिलाकर उपयोग किया जा सकता है। जब पूरा code migrate हो जाता है, तो उसे ऐसे universal binary के रूप में compile किया जा सकता है जो सभी CPython versions, PyPy या GraalPy पर काम करे
• Debug mode: memory leak, objects की गलत lifetime, API के गलत उपयोग आदि को आसानी से पहचान सकता है
• बेहतर API: standard Python/C API की सीमाओं को पार करता है, अधिक consistent और बेहतर quality वाले extension बनाता है, और इसे इस तरह डिज़ाइन किया गया है कि bugs आना कठिन हो
• विकास की क्षमता: जैसा कि PEP 620 में अच्छी तरह संक्षेपित किया गया है, standard Python/C API कई internal implementation details को उजागर करता है, जिससे C API का विकास कठिन हो जाता है। HPy इन सभी internal implementation details को छिपाता है, इसलिए यह समस्या नहीं होती

वर्तमान स्थिति

• HPy पर सक्रिय रूप से development चल रहा है। 0.9.0 नवीनतम alpha release है, लेकिन यह जल्द ही alpha स्थिति से बाहर आएगा और stable release की दिशा में काम हो रहा है
• HPy ABI अब इतना स्थिर महसूस होता है कि आने वाली releases में backward और forward binary compatibility के वादे निभाए जा सकें
• ऐसा माना जाता है कि API अब इतने use cases को cover करता है कि महत्वपूर्ण packages को migrate किया जा सके, खासकर numpy port को देखें
• porting guide और व्यापक documentation, विशेष रूप से API reference, भी उपलब्ध हैं
• design discussions और नई requirements के लिए हमेशा खुले हैं

HPy-compatible extension

• ultrajson-hpy: HPy पर port किया गया पहला वास्तविक module
• piconumpy: जैसा कि नाम से स्पष्ट है, custom types को define करने वाला एक minimal numpy-जैसा module
• numpy: महत्वाकांक्षी लक्ष्यों में से एक numpy को HPy पर port करना है और इस अनुभव का उपयोग API design को बेहतर समझने के लिए करना है। यह port test suite pass करने के बहुत करीब है
• matplotlib: NumPy पर dependency होने के कारण universal mode में migration अभी पूरी तरह समाप्त नहीं हुआ है। HPy, legacy compatibility API देता है ताकि HPy में legacy C API functions को कॉल करना जारी रखा जा सके और test suite सफलतापूर्वक चल सके
• kiwi-solver: Matplotlib की dependency, जिसे universal mode में पूरी तरह port कर दिया गया है

GN⁺ की राय

• HPy, Python/C API की सीमाओं को पार करके बेहतर extensibility और portability देने वाला एक बेहद आशाजनक project है
• खास तौर पर PyPy और GraalPy जैसे वैकल्पिक Python implementations में performance improvement की बड़ी संभावना इसे आकर्षक बनाती है
• legacy C API से migration कठिन हो सकता है, लेकिन HPy एक gradual migration path देता है, जिससे यह प्रक्रिया काफी अधिक manageable बन जाती है
• HPy को अपनाते समय मौजूदा build systems और distribution pipelines के साथ integration, upstream projects की स्वीकृति, और स्वयं HPy की maturity व stability पर विचार करना चाहिए
• HPy जैसे समान लक्ष्य वाले अन्य projects में Cython और Rust का PyO3 शामिल हैं। ये HPy से इस मायने में अलग हैं कि ये low-level C API की जगह high-level language का उपयोग करते हैं

[GN⁺]

Hacker News टिप्पणियाँ

• C API पर काम करने का सबसे झंझट वाला हिस्सा compile/link flags सेट करना है। python3-config सिर्फ OS स्तर पर काम करता है, और pip से इंस्टॉल किए गए packages तक पहुँचने के लिए इसका उपयोग करना कठिन है। python3 -m venv ऐसे scripts नहीं बनाता, और anaconda/miniconda भी समस्या है। हर package hardcoded python3 -c "import sys: print..." कॉल्स से build scripts को दूषित कर देता है। CPython में python3 -m sysconfig --json flag जोड़ने के लिए एक PR खोला गया है

• Python भाषा का एक ही implementation पर बहुत अधिक केंद्रित होना लंबे समय में उसकी सफलता के लिए खतरा हो सकता है। Web servers, command-line programs, और embedded devices की ज़रूरतें अलग-अलग होती हैं। अगर यह project Python के C API को ऐसे किसी विकल्प से बदलने में सफल होता है जो implementation details को उजागर न करे, तो alternative implementations को maintain करना और नई तकनीकों के साथ experiment करना आसान हो सकता है

• जिज्ञासा है कि क्या यह project version-independent Python bindings देता है। अभी हर version के लिए bindings अलग से build करनी पड़ती हैं, और इससे CI/CD समय काफी खर्च होता है

• HPy extensions और Cython/pybind11 implementations की performance और development time के हिसाब से तुलना करने वाला benchmark दिलचस्प होगा

• यह स्पष्ट नहीं है कि यह project PyBind11 या nanobind जैसी libraries के साथ कैसे fit होता है। इन्हें उसी तरह इस्तेमाल करने के लिए शायद फिर से लिखना पड़ेगा

• जिज्ञासा है कि आजकल C में लिखे गए नए extensions कितने बन रहे हैं। मुझे लगा था कि ज़्यादातर चीज़ें Boost Python, pybind, PyO3 जैसी हैं

• CPython bindings को न्यूनतम overhead के साथ implement करने के बारे में अक्सर पोस्ट करता हूँ, और कुछ recommendations, questions, और concerns साझा करना चाहता हूँ। HPy project के landing page और repository के README को फिर से संरचित करना अच्छा होगा। अगर PyPy, GraalPython, और दूसरे Python runtimes के समर्थन में कुछ आँकड़े हों, तो बात अधिक प्रभावशाली लगेगी

• HPyContext जैसे encapsulated context object का उपयोग multi-threaded Python के भविष्य या complex environments में उपयोगी है। लेकिन अगर HPyContext को CPython के singleton पर redirect किया जाता है, तो इससे समस्या हल नहीं होगी

• 2019 का benchmark CPython के METH_FASTCALL calling convention का उल्लेख करता है, लेकिन उसकी तुलना नहीं करता। अगर performance महत्वपूर्ण है, तो string formatter के बिना tuple से सीधे arguments parse करना बेहतर है

• जिज्ञासा है कि क्या Python में luajit के ffi जैसा कोई सरल तरीका है, जहाँ C headers दिए जाएँ, shared library लोड की जाए, और structs का उपयोग तथा functions को call किया जा सके

• Python से Go को call करने में रुचि है, और gopy cgo के लिए Python bindings generate करता है। HPy<->cgo में शायद कम overhead हो सकता है

• कल्पना करें कि अगर यह काम 20 साल पहले पूरा हो गया होता, तो Python ecosystem कितना अलग होता