Re: RFC: prototype of C extensions using the Python limited API

On 18/06/2026 21:46, Tom Tromey wrote:
> Matthieu> The prototype is organized as follows:
> Matthieu> - include/
> Matthieu>   - py-ref.hpp: copied from GDB. Addition of a clear() method in gdbpy_ref_policy.
> 
> Do we really need this?
> 
> What if gdb_py_ref is a subclass that adds a custom method instead?

This is for cases when a 'gdbpy_ref<> *' is a member of a Python object.
Py_CLEAR and Py_VISIT have to be called on the 'PyObject *' owned by gdbpy_ref.
This case does not appear in the prototype. I have only one occurrence inside GDB (which I 
introduced), which is perfectly replaceable by a raw 'PyObject *'. It does not seem a big deal to 
discard this.

> 
> I still haven't really read the code.  It's kind of difficult in this
> form.
> 

I just noticed that the patch was not inlined properly in the email. I usually use git-send-email 
for this, but had to add the patch manually here. I used Thunderbird to send it, with 
"mailnews.send_plaintext_flowed = true" so I would have expected the patch to be inlined.

Sorry for this. I can retry to send the inlined patch again.
Is there anything else I can do to make things easier for you ?

> Matthieu>     + gdbpy_heap_type: generic logic for dynamically-allocated types
> Matthieu>     (tp_traverse, tp_clear, tp_dealloc)
> 
> I don't understand why these can't just be methods of the implementation
> class, by which I mean the subclasses of PyObject.  If needed we could
> make an intermediary base class that interposes between the
> implementation and PyObject like
> > struct intermediary : public PyObject {};
> struct type_object : public intermediary { ... };  // eg
> 

The Python object is allocated by Python with PyObject_GC_New, so no C++ initialization is 
performed. Given this constraint, I am not sure that this intermediate class would work.
I haven't tried to check.

Additionally, for the types requiring a __dict__, I noticed that all those inheritances cause more 
issues than it helps.

> Matthieu> I don't expect a thorough review of all the code, but a
> Matthieu> validation of the approach.
> 
> I'll try to send more next week.
> 
> 
> Tom

Matthieu