cc@encukou@serhiy-storchaka@zooba

There is PyObject_Type().

I don't understand your remark. Are you suggesting to reimplement Py_TYPE() on top of PyObject_Type()? Py_TYPE() returns a borrowed reference, PyObject_Type() returns a strong reference.

Py_TYPE was defined as a macro, it depends on the internal structure of PyObject. If you need to use the limited C API, use PyObject_Type() instead of Py_TYPE().

Py_TYPE was defined as a macro, it depends on the internal structure of PyObject. If you need to use the limited C API, use PyObject_Type() instead of Py_TYPE().

Py_TYPE() is very commonly used in C extensions. Having to switch to PyObject_Type() is a lot of work. I don't want to force C extensions maintainers to do that. I only want to hide the implementation details (access toPyObject.ob_type member, maybe with an atomic operation in Free Threading).

It's not convenient to have to release a reference when using PyObject_Type(), compared to Py_TYPE().

Has not C API returning a borrowed reference been frowned upon lately? Strictly speaking, Py_TYPE() is incompatible with Free Threading.

If you want to use the limited C API, use PyObject_Type(). If you prefer performance and convenience, use Py_TYPE() and the GIL.

I don't get it. The stable ABI is guaranteed to be stable. Py_TYPE() is part of the stable ABI. I'm not asking to add it. Only to change its implementation.

Than what is the point of changingPy_TYPE()? If you do not use the limited C API, you rely on implementation details. If you do not want to rely on them, usePyObject_Type().

Than what is the point of changing Py_TYPE()?

As written previously, I am trying to avoid accessing PyObject members directly. This change is part of this project, even if it doesn't disallow accessing PyObject members yet.