<story><title>Hello, HPy</title><url>https://hpyproject.org/blog/posts/2021/03/hello-hpy/</url></story><parent_chain></parent_chain><comment><author>dmw_ng</author><text>This looks like the holy grail of extension development, effectively a Python runtime HAL, it&amp;#x27;s wildly exciting. Getting anything to work optimally on PyPy and CPython more or less means writing it twice. CFFI overhead on CPython really sucks for anything where the runtime of the wrapped function does not eclipse the overhead of the binding. HPy looks like a fantastic approach.&lt;p&gt;Only complaint from a quick scan -- carrying over that horrid PyArg_Parse() API. It&amp;#x27;s huge, needs varargs, isn&amp;#x27;t type safe, repeatedly rebuilds strings to look them up in kwargs, and isn&amp;#x27;t even all that convenient to use. Also, if you haven&amp;#x27;t dealt with a SEGV due to PyArg_Parse() before, it means you probably have never tried to write an extension&lt;p&gt;PyPy will become about 1000x more practical if something like this ever makes it into Cython. That would make it easy to bring over huge swathes of existing extensions like lxml.</text></comment>
<story><title>Hello, HPy</title><url>https://hpyproject.org/blog/posts/2021/03/hello-hpy/</url></story><parent_chain></parent_chain><comment><author>chrisseaton</author><text>We have this same problem in Ruby - implementing the Ruby C extension API if you aren&amp;#x27;t exactly the same as the reference Ruby implementation is extremely challenging. I think Charlie Nutter proposed something like this for Ruby in the past &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;headius&amp;#x2F;xni&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;headius&amp;#x2F;xni&lt;/a&gt;.</text></comment>