Re: [RFC 0/4] Better Python safety

[Matthieu Longo <matthieu.longo@arm.com>]

On 22/02/2026 19:49, Tom Tromey wrote:
> * I think the approach to handling subclasses of PyObject could be
>    greatly improved.  In particular I think we could use real C++
>    classes by judicious use of placement new and explicit destructor
>    calls.  The "corresponding_object_type" stuff you'll see in here is
>    sort of a gesture in this direction (though that code also helps
>    with some type-safety elsewhere as well).  Essentially I think we
>    could end up making new instances with just 'new'.
> 
>    I didn't want to really touch this until the stable ABI work related
>    to type-instantiation is done.
> 

Yes please :)

> * Finally gdb is using PyObject_New a lot but my reading while
>    researching this series indicates that this is wrong.  However the
>    wrongness is still (I guess temporarily) preserved in a wrapper in
>    this series.> 
> Tom
> 

I haven't published the patch series migrating all the C extension types, but what I discovered is summarized in https://docs.python.org/3/howto/isolating-extensions.html#heap-types.

Specifically this paragraph:

   > Instances of heap types hold a reference to their type. This ensures
   > that the type isn’t destroyed before all its instances are, but may
   > result in reference cycles that need to be broken by the garbage collector.

   > To avoid memory leaks, instances of heap types must implement the
   > garbage collection protocol. That is, heap types should:
   >  * Have the Py_TPFLAGS_HAVE_GC flag.
   >  * Define a traverse function using Py_tp_traverse, which visits the
   >    type (e.g. using Py_VISIT(Py_TYPE(self))).

So after the migration, all the extension types have the Py_TPFLAGS_HAVE_GC flag, are allocated via PyObject_GC_New(), and every PyType_Slot sets Py_tp_traverse, Py_tp_clear, and Py_tp_dealloc.

Some of the types had circular dependencies due to a type referencing the other one similarly to what happens between two nodes of a doubly linked list. In those cases, the circular dependency have to be broken.
Also, some types already should have required garbage collection management even with static types.

Are your findings converging with mine ?

Matthieu