[Python-Dev] PEP 384 status

"Martin v. Löwis" martin at v.loewis.de
Sun Sep 12 22:26:54 CEST 2010

> That said, looking at the PEP, I was wondering whether fields such as
> ob_type, ob_refcnt, ob_size have to be directly accessible, rather than
> through a macro-turned-into-a-function such as Py_REFCNT().

That they are macros still is primarily for performance reasons. For
ob_type, that may be questionable; for Py_INCREF, I hope you agree that
it's really desirable for it to be inline.

However, more importantly, user-defined objects need to start with the
standard object header. I really see no way to let extensions define
types without them also being able to access their own struct fields,
which in turn requires compile-time (ABI) knowledge of PyObject_HEAD.

This is also the reason why Py_TRACE_REFS can't be supported in the ABI:
it increases sizeof(PyObject), and thus shifts all user fields in the

I actually *do* have a priori knowledge of what might happen in the
future :-): If we were to change the layout of the object header
in a significant way, then the majority of extension modules would
break - not only on the binary level, but also on the source level.
So any change to this likely justifies calling it Python 4.
(I would be that even Python 4 keeps that structure)


More information about the Python-Dev mailing list