<mattip>
Hodgestar: how would an implicit transition to hpy-functions take place given code like in the example:
<mattip>
def add_int(a: int, b:int):
<mattip>
return a + b
<mattip>
so cython would parse this into a number of nodes: a top-level function node, then many children nodes (add, allocate assign)
<mattip>
currently some of these nodes (in the general case) can be represented as hpy code, and some not
<mattip>
and it would be nice to let the user know "your function is completely hpy-compatible" or not
<mattip>
but then there would be users who don't care
<mattip>
so by marking the function: "please hpy me", we signal:
<mattip>
- we expect the whole function to be fast on alternative pythons
<mattip>
- if not, let the user know
mattip_ has joined #hpy
mattip has quit [Quit: Leaving]
mattip_ has quit [Remote host closed the connection]
mattip has joined #hpy
mattip has quit [Remote host closed the connection]
mattip has joined #hpy
<Hodgestar>
mattip: I think I see hpy as more of a build / compilation option for Cython, so those could be warnings while building the module?
<Hodgestar>
mattip: Although it's a bit odd because your add_int doesn't reference Python.h at all, so it would emit code that uses Python.h as an intermediate step while we're building the HPy backend. It's not a user facing concern.
<Hodgestar>
If I think about your "please hpy me" decorator, you'd wanting something which says "please raise an error if this ends up being a legacy method"?
<mattip>
yes
<mattip>
"add_int doesn't reference Python.h at all" - not sure what you mean
<mattip>
could you show an example of good cython code that explicitly references Python.h