<steve_s>
I am looking into implementing the module state. The issue there is that the current traverse trampoline calls _HPy_PyObject_Payload to get the pointer to be sent to the actual tp_traverse, but in the case of a module, we need HPyModule_GetState.
<steve_s>
I am thinking about adding a new HPy specific slot, say, mp_traverse, that would generate the right trampoline using a new HPyFunc_Signature. Alternative would be to add a check for a module to the current tp_traverse trampoline, but it seems inefficient to me. Thoughts?
jboi has joined #hpy
jboi has quit [Remote host closed the connection]
<Hodgestar>
Is the issue just that a module needs a different default tp_traverse?
<Hodgestar>
(or at least different behaviour0
<Hodgestar>
)
jboi has joined #hpy
jboi has quit [Remote host closed the connection]
jboi has joined #hpy
the_drow has joined #hpy
ronny has joined #hpy
jevinskie[m] has joined #hpy
jboi has quit [Quit: Client limit exceeded: 20000]
jevinskie[m] has quit [Quit: Client limit exceeded: 20000]
ronny has quit [Quit: Client limit exceeded: 20000]
the_drow has quit [Quit: Client limit exceeded: 20000]
<steve_s>
It need a different CPython trampoline. tp_traverse trampoline extracts the "struct" from the PyObject to pass it to HPy's tp_traverse. For modules, we need to pass PyModule_GetState.
<steve_s>
I would argue that types' traverse is just a different thing to modules' traverse in HPy (getting argument with different meaning, although void* in both cases). In CPython it is PyObject (the type or module) in both cases, which makes it simple to reuse the same thing for both
<antocuni>
steve_s: mp_traverse would be HPy-specific, right?
<steve_s>
yes
<antocuni>
in other words, the hpy user writes an mp_traverse for its module, and hpy automatically generates a cpython-ready tp_traverse?
<steve_s>
yes, it would correspond to tp_traverse for modules in CPython, i.e., when porting a module with state you'd port its tp_traverse to HPy and as a part of that you'd use different "slot" mp_traverse, which would generate cpython ready tp_traverse under the hood, everything else re tp_traverse migration would be the same as for types
<antocuni>
it sounds reasonable
<antocuni>
why "mp"? What does it stand for?
<steve_s>
I wanted to follow the naming tp_something, maybe m_traverse would be better (@fangerer suggestion). tbh I am not sure what the "p" stands for in "tp_"?
<antocuni>
I think it's TyPe
<steve_s>
yeah, that sound's right. So m_ looks better to me now
<steve_s>
or md_, but I like m_ better
<antocuni>
I think m_ is better
<antocuni>
e.g., in CPython struct _typeobject contains fields like tp_name, tp_flags etc, and I think that's where the tp_ in tp_traverse come from
<antocuni>
and PyModuleDef contains m_name, m_doc, m_size, etc, so it seems CPython choose to just use m_
<antocuni>
if we want to depart from the historical prefix, maybe HPy_mod_traverse looks better and it's less obscure that HPy_m_traverse though
FFY00_ has joined #hpy
FFY00 has quit [Ping timeout: 250 seconds]
<fangerer>
Hi everyone, let's do our monthly call on Thursday (February 3rd at 10a CET / 9a UTC).