> 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 object. 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) Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
