Antonio Cuni

To elaborate Armin's answer; currently HPy is designed around two concepts: - a C API: this is what the C programmer is supposed to use, and includes commodities such as...

I agree that HPy should be usable also without macros/varargs, etc. > The same actually holds for suggestions to access the context struct directly (like ctx->h_None). Note that in the...

> Yeah, this was confusing. What I meant (and didn't write, because I was staring at that header) was a global symbol HPy_GetNone(ctx) (as you suggested before. I think you...

> * What about `HPyDup_None(ctx)`? I thought of it as well, but I don't like it too much. From a high-level point of view, what it returns is a handle...

> * The only reasonable operation to do with them is calling `HPy_Dup`. I correct myself here. There is at least another reasonable thing to do with `h_None` & co.:...

> Won't OPs point no. 2 apply to `HPy_(Get)None` as well? Name of the function does not clearly state if the handle is some kind of a singleton None object...

> We could define a list of constants via an enum or defines and then have one function `HPy_GetType(ctx, HPY_BOOL_TYPE)` that returns a new handle to the specified type. >...

> Isn't enums vs lots of generated methods orthogonal to the usability issue with `HPy_Is(ctx, h, ctx->h_None)` vs. `return HPy_Dup(ctx, ctx->h_None)`? yes, I agree. > My 2c is that `ctx->h_None`...

This is a summary of what we do after merging #338 : * The final goal is to be able to write something like this ```python from setuptools import setup,...

> Please, correct me if I'm wrong @antocuni but I guess this is still the best solution we have? > [#179 (comment)](https://github.com/pyscript/pyscript/issues/179#issuecomment-1119616160) yes it is