Re: [PATCH] Use the "O!" format more in the Python code

[Paul Koning <paulkoning@comcast.net>]

> On Feb 27, 2026, at 2:58 PM, Tom Tromey <tom@tromey.com> wrote:
> 
>>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:
> 
> Paul> Also, any type can be subclassed.  That
> Paul> last point is not true for types defined in C code, unless the code
> Paul> allows it to happen.  In general it should do so; it's very rare
> Paul> indeed for it to be "the right thing" for a type not to allow
> Paul> subclasses.
> 
> In gdb we've been fairly selective with this.
> 
> I looked it up and you have to set Py_TPFLAGS_BASETYPE, which we do in
> 13 of the classes that gdb implements.
> 
> Maybe we should do this everywhere?  But if we did that then wouldn't we
> also want to implement the 'dict' feature everywhere as well?

You mean in the sense that an object acts as if it has a dictionary inside, holding its attributes?  I'm not sure if that is needed for the GDB (base) classes.  Consider "slotted" objects, which don't have one, but can be subclassed and the subclass objects may have a dictionary, or not, at the discretion of the subclass author.

> I'm not sure there's a big advantage to it or need for it though.
> So maybe it's just busy-work.
> 
> I've been hoping to transition the internal types to be real C++ types,
> like give them constructors and destructors, initializers, etc.  But
> maybe it's not really possible with the Python lifetime model, at least
> when subclassing is available.

Python classes have construtors and destructors, but they work differently than C++.  Especially destructors because it isn't necessarily obvious when they will be called, at least for some scenarios where things aren't freed until the garbage collector gets there.

It's indeed possible that for some classes subclassing is unlikely to be wanted.  But I do remember, some years ago, wanting to subclass a GDB type and finding I could not.  I no longer remember which class it was, unfortunately.

	paul