I am traveling and have no keyboard right now, but it looks like this thread is confusing the slots that a type gives to its *instances* and extra slots in the type object itself. Only the latter are a problem.

I also would like to hear more about the problem this is trying to solve, when th real-world examples. (E.g. from pydantic?)

On Tue, Apr 26, 2022 at 11:57 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.)


Cheers,


/arry

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YU3PJKPMJZNWKLZUG3JCJFGFOKGMV2GI/
Code of Conduct: http://python.org/psf/codeofconduct/
--
--Guido (mobile)