Hey! First of all, cool to see some activity on this front! I’ve written a fair share of pure CPython bindings and regularly post about implementing them with

Hey! First of all, cool to see some activity on this front! I’ve written a fair share of pure CPython bindings and regularly post about implementing them with minimal overhead (<https://ashvardanian.com/posts/discount-on-keyword-arguments-in-python/ https://ashvardanian.com/posts/discount-on-keyword-arguments...>) and would love to share a few recommendations, questions, and concerns :) Just a suggestion to help you grow—I'd restructure the landing page (<https://hpyproject.org/ https://hpyproject.org/>) and the README of the repo (<https://github.com/hpyproject/hpy https://github.com/hpyproject/hpy>). It could benefit from some examples to clarify the "Nicer API" bullet point. Maybe these could be taken from the API documentation page (<https://docs.hpyproject.org/en/latest/api.html https://docs.hpyproject.org/en/latest/api.html>). The page could also be more convincing with some supporting stats in favor of PyPy, GraalPython, and other Python runtimes. A reader like me might not be sure if they have enough usage and are stable enough. Avoiding singletons and having encapsulated context objects like `HPyContext` is definitely a great thing to have, especially in the multi-threaded Python future or in complex environments with multiple sub-interpreters. But this doesn't really solve the problem if, under the hood, the `HPyContext` still redirects to CPython's singleton. I've also looked at the linked benchmarks (<https://pypy.org/posts/2019/12/hpy-kick-off-sprint-report-1840829336092490938.html https://pypy.org/posts/2019/12/hpy-kick-off-sprint-report-18...>). They are dated from 2019, five years ago, and already mention CPython's `METH_FASTCALL` fast calling convention, but it seems like they are not compared to it. In either case, parsing arguments from one "ll" string specifier is hardly a detailed benchmark if the underlying magic isn't explained. I occasionally do one-off benchmarks as well, but it's better to describe the principle—why the thing is supposed to be faster. For example, if you're concerned about performance, you'd just parse the arguments directly from the tuple without string formatters—like this: <https://github.com/ashvardanian/SimSIMD/blob/80cc4bcaddbdee9a0c0e991e13376c234aff3b3f/python/lib.c#L929-L1066> It’s more error-prone, but it would be cool to see if a high-level solution can achieve under a 10% latency penalty. Hope this is useful :)