On 26 Apr 2022, at 20:52, Larry Hastings <larry@hastings.org> wrote:
On 4/25/22 23:56, Ronald Oussoren wrote:
A problem with this trick is that you don’t know how large a class object can get because a subclass of type might add new slots. This is currently not possible to do in Python code (non-empty ``__slots__`` in a type subclass is rejected at runtime), but you can do this in C code. Dang it! __slots__! Always there to ruin your best-laid plans. *shakes fist at heavens*
I admit I don't know how __slots__ is currently implemented, so I wasn't aware of this. However! The first part of my proto-PEP already proposes changing the implementation of __slots__, to allow adding __slots__ after the class is created but before it's instantiated. Since this is so late-binding, it means the slots wouldn't be allocated at the same time as the type, so happily we'd sidestep this problem. On the other hand, this raises the concern that we may need to change the C interface for creating __slots__, which might break C extensions that use it. (Maybe we can find a way to support the old API while permitting the new late-binding behavior, though from your description of the problem I'm kind of doubtful.)
I used the term slots in a very loose way. In PyObjC I’m basically doing: typedef struct { PyHeapTypeObject base; /* Extra C fields go here */ } PyObjCClassObject; Those extra C fields don’t get exposed to Python, but could well be by using getset definitions. This has worked without problems since early in the 2.x release cycle (at least, that’s when I started doing this in PyObjC), and is how one subclasses other types as well. “Real” __slots__ don’t work when subclassing type() because type is a var object. That’s “just” an implementation limitation, it should be possible to add slots after the variable length bit (he says while wildly waving his hands). Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/