Neil Schemenauer schrieb am 28.02.19 um 21:42:
On 2019-02-28, Stefan Behnel wrote:
Py_INCREF() needs to return a new handle (whether that's a pointer or not is an unimportant detail for now).
I don't follow. Why does it have to return a new handle? Py_INCREF should mutate the object. Are you thinking of some kind of immutable handle type?
Something that doesn't require refcounting, yes. Could be a pointer or an index into some object ID mapping array. It would mean that pointer inequality doesn't rule out object identity anymore, because multiple handles could point to the same object, but it would provide an alternative to reference counting because each handle would be a single unique reference.
Your proposal of making it a pointer to a refcount would be a way to keep it backwards compatible – if that's wanted. It's not the only option, though.
I understand that "obj->ob_type" might be problematic (although that does not even seem sure yet), but what is the problem with "tp->tp_something"?
You are forcing all Python runtimes that want to support the C API to have the same memory layouts for type objects.
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.
Stefan