On Thu, Feb 28, 2019 at 1:10 PM Stefan Behnel email@example.com wrote:
Not necessarily. I'm just suggesting to keep the current vtable set (a.k.a. slots) to allow for fast protocol usages. That doesn't mean it's the "memory layout for type objects", especially not the one that CPython itself is tied to internally. PyTypeObject currently mingles multiple things, at least a) being an object itself, b) allowing for pointer type tests, c) describing the type/configuration/behaviour of an object and d) providing access to protocols. The different use cases could be separated.
Regarding d, I am curious to know, given that the set of entities in protocols is limited, do you think abstracting away the protocol access with API functions could provide the same properties of a vtable without having the vtable itself become API?
This would benefit systems that chose to not have a direct pointer from instances to their class or vtable. For them, as even big applications tend to have only order tens of thousands of types, encoding the type of an object in a whole 64-bit pointer wastes space. Instead, the instance type is represented as a small integer ID leaving the rest of the of header (which, ideally, is no more than a word) for other metadata.