scoder

I mostly agree with @da-woods regarding the code writer changes. Anything that is specific to the way a syntax node (or a certain kind of nodes) generates code should stay...

> While it is common to define and fill a static type struct in the C API, for HPy we will need to generate a type specification. We already generate...

> Quoting from https://docs.hpyproject.org/en/latest/overview.html: > > > handles are intended to be short-lived, but sometimes one needs a long-lived reference to a Python object. In HPy, we call this long-lived...

> Cython should only generate HPy code if this option is enabled, right? Yes. And it should be enabled by default, as soon as there is anything useful in the...

> Functions that return borrowed references and following increfs are in general a problem (in particular, function make_owned_reference doesn't work for HPy). Why not? Doesn't it just `dup()` a handle...

> in HPy you need to use a tuple builder I wonder if we could just generate an inline helper function for each tuple length, in a new code writer...

The only way to determine the path of the current module at module init time is [PEP 489](https://www.python.org/dev/peps/pep-0489/), and that cannot generally be implemented for an arbitrary extension module. Using...

The normal approach would be to install the Cython source files together with the binaries so that they can be looked up for tracebacks etc., just like Python finds the...

Enough of PEP-489 is implemented now to make this work.

Phew, this seems difficult to argue with these days. The intention of Cython language semantics is "Python by default, unless you opt out into C". In your example, you kind...