<mkoubaa>
I think the mental model of "the API is mostly a struct of pointers to functions" is hard to grasp initially. However, this is exactly what a vtable looks like and most people can follow that. I think HPy can do a better job of explaining why it made that choice for HPyContext
<mkoubaa>
The HPy github repo does a poor job of saying "this is the definition of the HPyContext in this header file", instead relying on codegen. I don't fully understand why we don't just have a hand-crafted hpy.h that defines the API and then implementation-specific header files for universal, cpython, etc. But I also haven't made a big effort to understand the codegen system
<mattip>
mkoubaa: please consider submitting a PR or at least opening an issue. Your perspective as someone trying to learn via the documentation is critical for improvements
mkoubaa has quit [Ping timeout: 255 seconds]
Techcable has joined #hpy
<Hodgestar>
The public_api.h is sort of meant to be that file. The autogen exists largely because we have to maintain two implementations. I think documenting public_api.h and making that visible is a good sprint topic (I think it is even already on the list).
<Hodgestar>
It would be nice too if public_api.h was really just the real header file. I'm not sure if florian actually did that, or if we both also agreed that it was the way to go.
<Hodgestar>
Mark's "needs more docs" bug report was not really talking to HPy about what he was planning (it was a good issue to report though).