homepage

Today, CPython is leaking too many implementation through its public C API. We cannot easily change the "default" C API, but we can enhance the "limited" C API (when Py_LIMITED_API macro is defined). Example of leaking implementation details: memory allocator, garbage collector, structure layouts, etc.
Making PyObject an opaque structure would allow in the long term of modify structures to implement more efficient types (ex: list specialized for small integers), and it can prepare CPython to experiment tagged pointers.
Longer rationale:
* https://pythoncapi.readthedocs.io/
* https://pythoncapi.readthedocs.io/bad_api.html
* https://pythoncapi.readthedocs.io/optimization_ideas.html
I propose to incremental evolve the existing limited C API towards opaque PyObject, by trying to reduce the risk of breakage.
We may test changes on PyQt which uses the limited C API.
Another idea would be to convert some C extensions of the standard library to the limited C API. It would ensure that the limited C API contains enough functions to be useful, but would also notify us directly if the API is broken.

> Another idea would be to convert some C extensions of the standard library to the limited C API. It would ensure that the limited C API contains enough functions to be useful, but would also notify us directly if the API is broken.
First issues that I met when I tried that:
* C code generated by Argument Clinic is incompatible the limited C API: METH_FASTCALL, _PyArg_CheckPositional(), static _PyArg_Parser, etc. are excluded from the limited C API.
* PyTypeObject is opaque and so it's not possible to implement a deallocator function (tp_dealloc) which calls tp_free like:
 Py_TYPE(self)->tp_free((PyObject*)self);
* _Py_IDENTIFIER() is not part of the limited C API

New changeset a93c51e3a8e15f1a486d11d5b55a64f3381babe0 by Victor Stinner in branch 'master':
bpo-39573: Use Py_REFCNT() macro (GH-18388)
https://github.com/python/cpython/commit/a93c51e3a8e15f1a486d11d5b55a64f3381babe0

> it can prepare CPython to experiment tagged pointers
In September 2018, Neil Schemenauer did an experiment:
* https://mail.python.org/archives/list/capi-sig@python.org/thread/EGAY55ZWMF2WSEMP7VAZSFZCZ4VARU7L/
* https://github.com/nascheme/cpython/commits/tagged_int
More recent discussion on the capi-sig list:
https://mail.python.org/archives/list/capi-sig@python.org/thread/JPUNPN3AILGXOA3C2TTSLMOFNSWJE3QX/
See also my notes:
https://pythoncapi.readthedocs.io/optimization_ideas.html#tagged-pointers-doable
Wikipedia article: https://en.wikipedia.org/wiki/Tagged_pointer 

In the limited C API, Py_REFCNT() should be converted to:
static inline Py_ssize_t _Py_REFCNT(const PyObject *ob)
{ return ob->ob_refcnt; }
#define Py_REFCNT(ob) _Py_REFCNT(_PyObject_CAST(ob))
It would enforce the usage of newly added Py_SET_REFCNT() (PR 18389) and advertise that the object is not modified (const).
That would only be the first step towards a really opaque Py_REFCNT() function.

TODO: Add Py_IS_TYPE() macro:
#define Py_IS_TYPE(ob, tp) (Py_TYPE(ob) == (tp)) 
For example, replace:
 #define PyBool_Check(x) (Py_TYPE(x) == &PyBool_Type) 
with:
 #define PyBool_Check(x) Py_IS_TYPE(x, &PyBool_Type)
IMHO it makes the code more readable.
https://github.com/nascheme/cpython/commit/c156300592dc1eab234b74ed5b7cc90a020ab82b 

New changeset c86a11221df7e37da389f9c6ce6e47ea22dc44ff by Victor Stinner in branch 'master':
bpo-39573: Add Py_SET_REFCNT() function (GH-18389)
https://github.com/python/cpython/commit/c86a11221df7e37da389f9c6ce6e47ea22dc44ff

New changeset 0d76d2bd28ac815dabae8b07240ed002ac8fce2d by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() in abstract.c (GH-18390)
https://github.com/python/cpython/commit/0d76d2bd28ac815dabae8b07240ed002ac8fce2d

Py_TYPE() is commonly used to render the type name in an error message. Example:
PyErr_Format(PyExc_TypeError,
 "cannot convert '%.200s' object to bytearray",
 Py_TYPE(arg)->tp_name);
This code has multiple issues:
* It truncates type name to 200 characters: there is no Python exception, not even a marker to indicate that the string has been truncated
* It's only the short name: the qualified name (tp_qualname) would be more helpful. The best would be to generate the fully qualified name: module + qualname.
* Py_TYPE() returns a borrowed reference which is causing multiple issues: https://pythoncapi.readthedocs.io/bad_api.html#borrowed-references
In September 2018, I created bpo-34595: "PyUnicode_FromFormat(): add %T format for an object type name". But there was disagreement, so I rejected my change.
I started "bpo-34595: How to format a type name?" thread on python-dev:
* https://mail.python.org/archives/list/python-dev@python.org/thread/HKYUMTVHNBVB5LJNRMZ7TPUQKGKAERCJ/#3UAMHYG6UF4MPLXBZORHO4JVKUBRUZ53
I didn't continue this work (until now), since it wasn't my priority.

New changeset a102ed7d2f0e7e05438f14d5fb72ca0358602249 by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() macro in Python and Include directories (GH-18391)
https://github.com/python/cpython/commit/a102ed7d2f0e7e05438f14d5fb72ca0358602249

Make PyObject an opaque structure is also a first step towards the more ambitious project "HPy" project which is fully opaque:
https://github.com/pyhandle/hpy
This API is written from scratch and currently implemented on top on the existing C API.
The following article is a nice introduction to the overall idea:
https://morepypy.blogspot.com/2019/12/hpy-kick-off-sprint-report.html
From my point of view, the long term goal would be to get better performance on PyPy and having a single API for C extension which would be efficient on all Python implementations (not only CPython).
Currently, the C API is not only a performance issue to run C extensions on PyPy. It's also an issue in CPython. Because the C API leaks too many implementation details, we cannot experiment optimizations.
See also: https://pythoncapi.readthedocs.io/rationale.html 

New changeset 58ac700fb09497df14d4492b6f820109490b2b88 by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() macro in Objects directory (GH-18392)
https://github.com/python/cpython/commit/58ac700fb09497df14d4492b6f820109490b2b88

New changeset daa9756cb6395323d6f291efe5c7d7fdc6b2e9d8 by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() macro in Modules directory (GH-18393)
https://github.com/python/cpython/commit/daa9756cb6395323d6f291efe5c7d7fdc6b2e9d8

New changeset d2ec81a8c99796b51fb8c49b77a7fe369863226f by Victor Stinner in branch 'master':
bpo-39573: Add Py_SET_TYPE() function (GH-18394)
https://github.com/python/cpython/commit/d2ec81a8c99796b51fb8c49b77a7fe369863226f

To make PyObject opaque, we would have to convert Py_INCREF() and Py_DECREF() to opaque function calls. Example:
#define Py_XINCREF(op) Py_IncRef(op)
#define Py_XDECREF(op) Py_DecRef(op)
Benchmarks should be run to measure to overhead and balance the advantages and drawbacks.

Would a Py_TYPE_IS() macro help code readability?
For example:
 #define Future_CheckExact(obj) (Py_TYPE(obj) == &FutureType)
would become:
 #define Future_CheckExact(obj) (Py_TYPE_IS(obj, &FutureType))
Py_TYPE_IS() would be more efficient for tagged pointers.
I'm not sure about the macro name. Neil used Py_IS_TYPE(obj, type).
Note: Py_TYPE_EQ(obj, type) name sounds confusing since the first parameter is an object, whereas the second one is a type.

New changeset c65b320a95784d2b2133926921d67ac439259e9f by Victor Stinner in branch 'master':
bpo-39573: Use Py_TYPE() macro in object.c (GH-18398)
https://github.com/python/cpython/commit/c65b320a95784d2b2133926921d67ac439259e9f

New changeset b10dc3e7a11fcdb97e285882eba6da92594f90f9 by Victor Stinner in branch 'master':
bpo-39573: Add Py_SET_SIZE() function (GH-18400)
https://github.com/python/cpython/commit/b10dc3e7a11fcdb97e285882eba6da92594f90f9

You have merged so much PRs today. What they do?
PyObject cannot just be made an opaque structure. The user code reads and writes its fields directly and via macros. This change would break working code.
We can encourage the user code to prepare to making PyObject an opaque structure. We need to provide a stable C API for access of PyObject fields for this. Note that there is a performance penalty of using functions instead of direct access, so you should have very good reasons to do this.

> You have merged so much PRs today. What they do?
I merged changes which prepares CPython code base to make PyObject opaque. I only merged changes which should have no impact on performance, but prepare the API to make the structure opaque.
Right now, Py_SET_REFNCT() stills access directly to PyObject.ob_refcnt. But it becomes possible to make Py_SET_REFNCT() an opaque function call.
Do you see any issue with the changes that I already merged? Using PGO+LTO, static inline functions should be as efficient as the previous code using Py_REFCNT() & cie macros.
> PyObject cannot just be made an opaque structure. The user code reads and writes its fields directly and via macros. This change would break working code.
I'm trying to modifying the limited C API to make it possible: all access to PyObject fields should go through macros or function calls. The question is now how which fields are accessed and how.
> We can encourage the user code to prepare to making PyObject an opaque structure. We need to provide a stable C API for access of PyObject fields for this.
For the short term, I don't plan to make PyObject opaque, so I don't plan to enforce usage of Py_TYPE(), Py_SET_REFCNT(), etc.
> Note that there is a performance penalty of using functions instead of direct access, so you should have very good reasons to do this.
Yeah, replacing Py_REFCNT() macro with an opaque function call is likely to have an impact on performance. It should be properly measure, I'm well aware of that, I already wrote it in a previous comment ;-) I don't plan to push change such right now. And I will wait for the review of my peers (like you) for such change ;-)

New changeset 60ac6ed5579f6666130fc264d3b748ee9575e3aa by Victor Stinner in branch 'master':
bpo-39573: Use Py_SET_SIZE() function (GH-18402)
https://github.com/python/cpython/commit/60ac6ed5579f6666130fc264d3b748ee9575e3aa

"static inline" functions are not opaque - as they get inlined into 3rd-party compiled code, we can't change anything they reference, and so the structure layout is still fixed and has to be visible to the user's compiler.
I'm not totally against the changes, but it's worth pointing out that you aren't achieving what the issue title claims, so it's really just code cleanliness (and/or introducing macro-users to static inline functions ;) ).

> "static inline" functions are not opaque
I'm well aware of that :-) But once the CPython code base will stop accessing directly PyObject fields directly, it would become possible to experiment changing PyObject layout, at least testing it in CPython.
First changes are just to prepare the code base to experiment the real change. But as Serhiy pointed out, the second part will have an impact on performance and so should be carefully benchmarked to balance advantages and drawbacks, even if it's only done in the limited C API.

New changeset 7f6f7eef5206858030cbe4f80a7c04b02781cc9a by Dong-hee Na in branch 'master':
bpo-39573: Use Py_TYPE() macro in ctypes.h (GH-18411)
https://github.com/python/cpython/commit/7f6f7eef5206858030cbe4f80a7c04b02781cc9a

FYI, I am working on to add Py_IS_TYPE macro. :)

Hi, guys. Is there value in adding `PyNone_Check` macro?(`_PyNone_Type` is not esposed to CAPI directly, so I am not sure about it)
If the answer is 'yes', i can add it ;)

> Hi, guys. Is there value in adding `PyNone_Check` macro?
"obj == Py_None" is a very common pattern.
You have check how it is done in HPy: https://github.com/pyhandle/hpy
See also bpo-39511: "[subinterpreters] Per-interpreter singletons (None, True, False, etc.)".

>"obj == Py_None" is a very common pattern.
>You have check how it is done in HPy: https://github.com/pyhandle/hpy
>See also bpo-39511: "[subinterpreters] Per-interpreter singletons (None, >True, False, etc.)".
Thanks, I will check it.

New changeset 968dcd9e7a4d3aa9aaa1dfca693adf60d6b71ce7 by Brandt Bucher in branch 'master':
bpo-39573: Fix bad copy-paste in Py_SET_SIZE (GH-18496)
https://github.com/python/cpython/commit/968dcd9e7a4d3aa9aaa1dfca693adf60d6b71ce7

New changeset d905df766c367c350f20c46ccd99d4da19ed57d8 by Dong-hee Na in branch 'master':
bpo-39573: Add Py_IS_TYPE() function (GH-18488)
https://github.com/python/cpython/commit/d905df766c367c350f20c46ccd99d4da19ed57d8

> Hi, guys.
By the way, please find another more inclusive way to say hi, see:
https://heyguys.cc/ 

> By the way, please find another more inclusive way to say hi, see:
https://heyguys.cc/
Oh, copy that. Sorry for my poor english.

New changeset d212c3c55d414203b0579e000d9f340f8cd11be7 by Dong-hee Na in branch 'master':
bpo-39573: PyXXX_Check() macros use Py_IS_TYPE() (GH-18508)
https://github.com/python/cpython/commit/d212c3c55d414203b0579e000d9f340f8cd11be7

New changeset 9aeb0ef9309384099e2f23bcee2240fbc096568e by Dong-hee Na in branch 'master':
 bpo-39573: Update clinic to use Py_IS_TYPE() function (GH-18507)
https://github.com/python/cpython/commit/9aeb0ef9309384099e2f23bcee2240fbc096568e

@vstinner would it be helpful if I went on a sweep looking for places we can use the new Py_IS_TYPE macro?
Getting away from Py_TYPE(op) would also mean a move to making the internals const-correct.

I'm hoping that a goal here is to make
static inline int _Py_IS_TYPE(PyObject *ob, PyTypeObject *type)
actually be
static inline int _Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type)

> Getting away from Py_TYPE(op) would also mean a move to making the internals const-correct.
Would you mind to explain how it's an issue to modify PyObject* temporarily during a function call? It's common to increase the object reference count to ensure that it doesn't go even while we use it.

New changeset 1b55b65638254aa78b005fbf0b71fb02499f1852 by Dong-hee Na in branch 'master':
bpo-39573: Clean up modules and headers to use Py_IS_TYPE() function (GH-18521)
https://github.com/python/cpython/commit/1b55b65638254aa78b005fbf0b71fb02499f1852

> Would you mind to explain how it's an issue to modify PyObject* temporarily during a function call?
It's not a problem to modify the PyObject* during a function call. However, many functions don't need to modify the object, but are still taking non-const PyObject* arguments.
For example if I have this code:
 if (Py_TYPE(deque) == &deque_type) {
That doesn't modify deque to check the type, but because Py_TYPE casts away the constness, deque can't be a const object.
However, with the new Py_IS_TYPE function:
 if (Py_IS_TYPE(deque, &deque_type)) {
and these two changes:
-static inline int _Py_IS_TYPE(PyObject *ob, PyTypeObject *type) {
+static inline int _Py_IS_TYPE(const PyObject *ob, const PyTypeObject *type) {
 return ob->ob_type == type;
 }
-#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(_PyObject_CAST(ob), type)
+#define Py_IS_TYPE(ob, type) _Py_IS_TYPE(((const PyObject*)(ob)), type)
the deque variable can be const.
Another example of a common pattern that I believe could benefit from this is Py_TYPE(ob)->tp_name. That could be turned into Py_TYPE_NAME(ob) and that would allow the ob to be a const pointer. 
If we can keep functions that don't modify the object to accept const PyObject* it will help make things safer in the long run.

> If we can keep functions that don't modify the object to accept const PyObject* it will help make things safer in the long run.
In my experience, trying to add "const" is quite painful, since the "const" has to be propagated to all functions called by the modified function. Python never used "const" with "PyObject*" because they are *so many* functions which really modify objects on purpose.
I don't see how adding "const" would help this issue "Make PyObject an opaque structure in the limited C API". If you consider that something should be changed, please open a *separated* issue.

All I'm saying is that I think Py_IS_TYPE is a great idea, and that Py_IS_TYPE should take const arguments, since its arguments are not modified. If you think that should go in a different ticket, then I can make that happen.

Just added a new PR to finish off the remaining places to use Py_IS_TYPE()
https://github.com/python/cpython/pull/18601 

New changeset dffe4c07095e0c693e094d3c140e85a68bd8128e by Andy Lester in branch 'master':
bpo-39573: Finish converting to new Py_IS_TYPE() macro (GH-18601)
https://github.com/python/cpython/commit/dffe4c07095e0c693e094d3c140e85a68bd8128e

New changeset 8767ce92d24d3687405848442e6c67cf0af1c657 by Andy Lester in branch 'master':
bpo-39573: Make Py_IS_TYPE() take constant parameters (GH-18799)
https://github.com/python/cpython/commit/8767ce92d24d3687405848442e6c67cf0af1c657

New changeset 557287075c264d2458cd3e1b45e9b8ee5341e0a1 by Andy Lester in branch 'master':
 bpo-39573: Use Py_IS_TYPE() macro to check for types (GH-18809)
https://github.com/python/cpython/commit/557287075c264d2458cd3e1b45e9b8ee5341e0a1

I created bpo-40170 "[C API] Make PyTypeObject structure an opaque structure in the public C API".

PyType_FromSpec() and PyType_Spec API are not currently compatible with opaque PyObject.
Example:
---
#define PyObject_HEAD PyObject ob_base;
typedef struct {
 PyObject_HEAD
 ...
} MyObject;
static PyType_Spec type_spec = {
 .name = "MyObject",
 .basicsize = sizeof(MyObject),
 ...
};
... = PyType_FromSpec(&type_spec);
---
sizeof(MyObject) requires to compute sizeof(PyObject).
Issue reported by Ronald Oussoren on python-dev:
https://mail.python.org/archives/list/python-dev@python.org/message/PGKRW7S2IUOWVRX6F7RT6VAWD3ZPUDYS/ 

The incompatibility mentioned in msg366473 is probably fixable by treating the PyObject header the same as the GC head structure. With some care this could mostly maintain binary compatibility by inserting some unused fields in PyObject_HEAD instead of the PyObject header when an extension targets a stable ABI version that has the PyObject header in-line.
This issue seems to be comparible to the "fragile instance variable" issue fixed in Objective-C 2.0, see <https://en.wikipedia.org/wiki/Objective-C#Non-fragile_instance_variables>. That was fixed by adding a level of indirection when accessing member variables.
Something like that is probably necessary to be able to subclass builtin types (other than object itself) in an extension.

New changeset 5e8ffe147710e449c2e935a4e2ff5cbd19828a8a by Hai Shi in branch 'master':
bpo-39573: Use Py_IS_TYPE to check for types (GH-19882)
https://github.com/python/cpython/commit/5e8ffe147710e449c2e935a4e2ff5cbd19828a8a

New changeset ad3252bad905d41635bcbb4b76db30d570cf0087 by Dong-hee Na in branch 'master':
bpo-39573: Convert Py_TYPE() to a static inline function (GH-20290)
https://github.com/python/cpython/commit/ad3252bad905d41635bcbb4b76db30d570cf0087

New changeset 7d847e29d76b178c2db66b180065771b4d90c78f by Dong-hee Na in branch 'master':
bpo-39573: Fix buildbot failure for tupleobject.c (GH-20391)
https://github.com/python/cpython/commit/7d847e29d76b178c2db66b180065771b4d90c78f

New changeset fe2978b3b940fe2478335e3a2ca5ad22338cdf9c by Victor Stinner in branch 'master':
bpo-39573: Convert Py_REFCNT and Py_SIZE to functions (GH-20429)
https://github.com/python/cpython/commit/fe2978b3b940fe2478335e3a2ca5ad22338cdf9c

> bpo-39573: Convert Py_TYPE() to a static inline function (GH-20290)
This change broke two projects:
* Cython: https://github.com/cython/cython/commit/d8e93b332fe7d15459433ea74cd29178c03186bd (FIXED)
* immutables: https://github.com/MagicStack/immutables/issues/46 

> bpo-39573: Convert Py_TYPE() to a static inline function (GH-20290)
This change broke pycurl:
https://github.com/pycurl/pycurl/pull/636
Extract of its current code:
"""
 /* Initialize the type of the new type objects here; doing it here
 * is required for portability to Windows without requiring C++. */
 p_Curl_Type = &Curl_Type;
 p_CurlMulti_Type = &CurlMulti_Type;
 p_CurlShare_Type = &CurlShare_Type;
 Py_TYPE(&Curl_Type) = &PyType_Type; 
 Py_TYPE(&CurlMulti_Type) = &PyType_Type; 
 Py_TYPE(&CurlShare_Type) = &PyType_Type; 
"""

To port code to Python 3.10, the following macro can be copied/pasted in your code. It defines Py_SET_SIZE() if it's not defined.
#if PY_VERSION_HEX < 0x030900A4
# define Py_SET_SIZE(obj, size) do { Py_SIZE(obj) = (size); } while (0)
#endif

Similar macro for Py_SET_TYPE:
#if PY_VERSION_HEX < 0x030900A4
# define Py_SET_TYPE(obj, size) do { Py_TYPE(obj) = (size); } while (0)
#endif

numpy fix defines Py_SET_TYPE() and Py_SET_SIZE() on old Python versions:
* https://github.com/numpy/numpy/commit/a96b18e3d4d11be31a321999cda4b795ea9eccaa
* https://github.com/numpy/numpy/pull/16417
In the whole numpy code base, only 5 lines have to be modified!

I proposed PR 20610 to enhance the documentation explaining how to port existing to code to Py_SET_SIZE() & cie.

New changeset dc24b8a2ac32114313bae519db3ccc21fe45c982 by Victor Stinner in branch 'master':
bpo-39573: Porting to Python 3.10: Py_SET_SIZE() macro (GH-20610)
https://github.com/python/cpython/commit/dc24b8a2ac32114313bae519db3ccc21fe45c982

Note: numpy was updated to also the use the macros using ", (void)0":
https://github.com/numpy/numpy/commit/f1671076c80bd972421751f2d48186ee9ac808aa 

See also bpo-40881 "--with-valgrind broken": unicode_release_interned() still used "Py_REFCNT(s) += 1;". It's now fixed by commit c96a61e8163c2d25ed4ac77cf96201fd0bdb945c.

> Another idea would be to convert some C extensions of the standard library to the limited C API. It would ensure that the limited C API contains enough functions to be useful, but would also notify us directly if the API is broken.
I created bpo-41111: "Convert a few stdlib extensions to the limited C API".

New changeset 8182cc2e68a3c6ea5d5342fed3f1c76b0521fbc1 by Victor Stinner in branch 'master':
bpo-39573: Use the Py_TYPE() macro (GH-21433)
https://github.com/python/cpython/commit/8182cc2e68a3c6ea5d5342fed3f1c76b0521fbc1

This also breaks pycurl:
https://github.com/pycurl/pycurl/pull/660
And breezy:
https://bugzilla.redhat.com/show_bug.cgi?id=1890880 (not yet reported upstream)
I don't understand the rationale for this change in depth, but does the benefit outweigh (yet another) backwards incompatibility?

> I don't understand the rationale for this change in depth, but
> does the benefit outweigh (yet another) backwards incompatibility?
I think you can have it both ways. Do you want a C API that is
stable over a long period of CPython releases or do you want to
continue to be able to look deep (i.e. non opaque PyObject*) into
CPython implementation internals?
During the sprint last week, we talked about how to provide a
compatible API, similar to what Pypy cpyext does. It would be
possible to provide a (nearly) fully compatible API with the
approach. It could get quite painful for CPython to maintain such a
thing however. E.g. cpyext has proxy objects (to maintain CPython
compatible structure layouts) but keeping those proxies in sync with
the internal VM object structures is expensive and tricky.
Certainly making PyObject opaque is going to break some 3rd party
code. Making it opaque for the non-limited API is not an option
IMHO because it breaks too much 3rd party code. Is making it
opaque for the limited C API going to break too much code? Maybe, I
don't know. Thanks for pointing out pycurl and breezy.

Correction: I think you *cannot* have it both ways.

Miro:
> This also breaks pycurl:
> https://github.com/pycurl/pycurl/pull/660
Right, see my previous comment, another PR was already proposed in May!
me:
> This change broke pycurl:
> https://github.com/pycurl/pycurl/pull/636
Merged pycurl fix:
https://github.com/pycurl/pycurl/commit/e633f9a1ac4df5e249e78c218d5fbbd848219042 

Miro:
> I don't understand the rationale for this change in depth, but does the benefit outweigh (yet another) backwards incompatibility?
I wrote PEP 620 "Hide implementation details from the C API" to explain the rationale:
https://www.python.org/dev/peps/pep-0620/ 

Another batch of broken projects:
PyPAM https://bugzilla.redhat.com/show_bug.cgi?id=1897264
bitarray https://bugzilla.redhat.com/show_bug.cgi?id=1897536
boost https://bugzilla.redhat.com/show_bug.cgi?id=1896382
duplicity https://bugzilla.redhat.com/show_bug.cgi?id=1896684
gobject-introspection https://bugzilla.redhat.com/show_bug.cgi?id=1893194
mercurial https://bugzilla.redhat.com/show_bug.cgi?id=1897178
pybluez https://bugzilla.redhat.com/show_bug.cgi?id=1897256
pygobject3 https://bugzilla.redhat.com/show_bug.cgi?id=1894522
pylibacl https://bugzilla.redhat.com/show_bug.cgi?id=1897529
pyside2 https://bugzilla.redhat.com/show_bug.cgi?id=1898974
rdiff-backup https://bugzilla.redhat.com/show_bug.cgi?id=1898980
Those are just the initial set of packages we have discovered so far. I think there will be more.

I wrote PR 23366 to revert the Py_TYPE() and Py_SIZE() changes: convert them back to macros to allow again "Py_TYPE(obj) = type;" and "Py_SIZE(obj) = size;" syntaxes.
Miro Hrončok:
> Another batch of broken projects:
> PyPAM https://bugzilla.redhat.com/show_bug.cgi?id=1897264
"Py_TYPE="
> bitarray https://bugzilla.redhat.com/show_bug.cgi?id=1897536
"Py_TYPE=/Py_SIZE="
> boost https://bugzilla.redhat.com/show_bug.cgi?id=1896382
"Py_TYPE="
> duplicity https://bugzilla.redhat.com/show_bug.cgi?id=1896684
"Py_TYPE="
> gobject-introspection https://bugzilla.redhat.com/show_bug.cgi?id=1893194
"Py_TYPE="
> mercurial https://bugzilla.redhat.com/show_bug.cgi?id=1897178
"Py_TYPE=/Py_SIZE="
> pybluez https://bugzilla.redhat.com/show_bug.cgi?id=1897256
"Py_TYPE="
> pygobject3 https://bugzilla.redhat.com/show_bug.cgi?id=1894522
"Py_TYPE="
> pylibacl https://bugzilla.redhat.com/show_bug.cgi?id=1897529
"Py_TYPE="
> pyside2 https://bugzilla.redhat.com/show_bug.cgi?id=1898974
"Py_TYPE="
> rdiff-backup https://bugzilla.redhat.com/show_bug.cgi?id=1898980
"Py_TYPE="
> Those are just the initial set of packages we have discovered so far. I think there will be more.
Well, since the PEP 620 is not accepted, I prefer to revert the Py_TYPE() and the Py_SIZE() changes for now. We should have a wider discussion on how to introduce incompatible changes into the C API before being able to push more incompatible changes which impact a so wide range of C extension modules.
One practical problem is how to estimate the number of broken Python projects to decide if an incompatible change can be introduced or not. When I did early experiment before merging the PR 20290, it seems like only a minority of C extensions rely on "Py_TYPE(obj) = type;" syntax. It's a common pattern to define a type statically. Pseudo-code:
---
PyTypeObject MyType = {...};
PyInit_MyExtension(...)
{
 Py_TYPE(&MyType) = ...;
 PyType_Ready(&MyType);
 ...
}
---
"Py_TYPE(&MyType) = ...;" is required since some C compilers don't support setting ob_type directly in the MyType static declaration. The type must be set at runtime.
Also I considered that the change is trivial enough to be accepable. Well, I was wrong, and that's why I'm not proposing to revert thes changes.
About the rationale for introducing C API incompatible changes, see the PEP 620.

New changeset 0e2ac21dd4960574e89561243763eabba685296a by Victor Stinner in branch 'master':
bpo-39573: Convert Py_TYPE() and Py_SIZE() back to macros (GH-23366)
https://github.com/python/cpython/commit/0e2ac21dd4960574e89561243763eabba685296a

New changeset e0251787d85950538cf2490c2c73cc680b153940 by Miro Hrončok in branch 'master':
bpo-39573: Remove What's new entry for Py_SIZE() (GH-23375)
https://github.com/python/cpython/commit/e0251787d85950538cf2490c2c73cc680b153940

> And breezy:
> https://bugzilla.redhat.com/show_bug.cgi?id=1890880 (not yet reported upstream)
Oh, I didn't notice that this project is broken by the Py_REFCNT() change. I expected it to be broken by the Py_TYPE() change as others.
Should we revert the Py_REFCNT() change as well? So far, breezy is the only impacted project, and the fix should be simple, no?
breezy uses "Py_REFCNT(self) -= 1;" instead of "Py_DECREF(self);" in its StaticTuple_Intern() function:
static StaticTuple *
StaticTuple_Intern(StaticTuple *self)
{
 PyObject *canonical_tuple = NULL;
 if (_interned_tuples == NULL || _StaticTuple_is_interned(self)) {
 Py_INCREF(self);
 return self;
 }
 /* SimpleSet_Add returns whatever object is present at self
 * or the new object if it needs to add it.
 */
 canonical_tuple = SimpleSet_Add(_interned_tuples, (PyObject *)self);
 if (!canonical_tuple) {
 // Some sort of exception, propogate it.
 return NULL;
 }
 if (canonical_tuple != (PyObject *)self) {
 // There was already a tuple with that value
 return (StaticTuple *)canonical_tuple;
 }
 self->flags |= STATIC_TUPLE_INTERNED_FLAG;
 // The two references in the dict do not count, so that the StaticTuple
 // object does not become immortal just because it was interned.
 Py_REFCNT(self) -= 1;
 return self;
}
But it also uses "Py_REFCNT(self) = 2;" to "revive dead object temporarily for Discard".
static void
StaticTuple_dealloc(StaticTuple *self)
{
 int i, len;
 if (_StaticTuple_is_interned(self)) {
 /* revive dead object temporarily for Discard */
 Py_REFCNT(self) = 2;
 if (SimpleSet_Discard(_interned_tuples, (PyObject*)self) != 1)
 Py_FatalError("deletion of interned StaticTuple failed");
 self->flags &= ~STATIC_TUPLE_INTERNED_FLAG;
 }
 len = self->size;
 for (i = 0; i < len; ++i) {
 Py_XDECREF(self->items[i]);
 }
 Py_TYPE(self)->tp_free((PyObject *)self);
}
It sounds like an optimization using a set of "interned" tuples. Maybe to reduce the memory footprint.

> And breezy:
> https://bugzilla.redhat.com/show_bug.cgi?id=1890880 (not yet reported upstream)
I reported the issue to breezy upstream:
https://bugs.launchpad.net/brz/+bug/1904868 

I created the https://github.com/pythoncapi/upgrade_pythoncapi project which updates automatically a C extension to newer C API. For example, it uses Py_TYPE(), Py_SIZE(), Py_REFCNT(), Py_SET_SIZE(), Py_SET_SIZE() and Py_SET_REFCNT() functions.

Status:
* Py_SET_REFCNT(), Py_SET_TYPE() and Py_SET_SIZE() functions added to Python 3.9.
* Python and Cython have been modified to use Py_TYPE(), Py_SET_REFCNT(), Py_IS_TYPE(), etc.
* pythoncapi_compat.h header file has been created to provide new functions to Python 3.6: https://github.com/pythoncapi/pythoncapi_compat
* Script has been created to upgrade C extensions to add support for Python 3.10 without losing support for old Python versions: https://github.com/pythoncapi/pythoncapi_compat
* PEP 620 "Hide implementation details from the C API" written
* Py_TYPE() and Py_SIZE() were converted to a static inline function to deny "Py_TYPE(obj) = type;" syntax, but this change has been reverted during Python 3.10 development cycle since it broke too many C extension modules. (msg381337)
TODO:
* Maybe add a new formatter for type names (msg361523)
* Avoid sizeof(PyObject) in PyType_FromSpec() (msg366473)
The purpose of this issue is only to fix the API part. Replacing static inline functions with opaque function calls (stable ABI) is not in the scope of this issue.

> immutables: https://github.com/MagicStack/immutables/issues/46
I proposed a fix: https://github.com/MagicStack/immutables/pull/52
> mercurial https://bugzilla.redhat.com/show_bug.cgi?id=1897178
I proposed a fix: https://bz.mercurial-scm.org/show_bug.cgi?id=6451 

> pyside2 https://bugzilla.redhat.com/show_bug.cgi?id=1898974
I proposed a fix upstream: https://bugreports.qt.io/browse/PYSIDE-1436 I also wrote a fix in Fedora: https://src.fedoraproject.org/rpms/python-pyside2/pull-request/7 The issue is now tracked in Fedora as: https://bugzilla.redhat.com/show_bug.cgi?id=1902618 

> bitarray https://bugzilla.redhat.com/show_bug.cgi?id=1897536
I created https://github.com/ilanschnell/bitarray/pull/109 

> boost https://bugzilla.redhat.com/show_bug.cgi?id=1896382
I proposed https://github.com/boostorg/python/pull/330 fix.
See also https://github.com/boostorg/python/pull/329 

Most projects broken by Py_TYPE and Py_SIZE changes have been fixed since last year. I succeeded to use my new pythoncapi_compat project on multiple C extensions. So I propose again to convert Py_TYPE and Py_SIZE macros to static inline functions: https://github.com/python/cpython/pull/26493
I also proposed to promote the pythoncapi_compat project in the "C API: Porting to Python 3.10" section of "What's New In Python 3.10?" on python-dev:
https://mail.python.org/archives/list/python-dev@python.org/thread/KHDZGCNOYEDUTSPAATUDP55ZSSQM5RRC/
I already announced the pythoncapi_compat project on the capi-sig last December:
https://mail.python.org/archives/list/capi-sig@python.org/thread/LFLXFMKMZ77UCDUFD5EQCONSAFFWJWOZ/ 

> So I propose again to convert Py_TYPE and Py_SIZE macros to static inline functions
+1

New changeset f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970 by Victor Stinner in branch 'main':
bpo-39573: Py_TYPE becomes a static inline function (GH-26493)
https://github.com/python/cpython/commit/f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970

@victor, git bisect tells me the change f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970 caused test_exceptions.ExceptionTests.test_recursion_in_except_handler to stack overflow only on windows debug builds. 3 windows buildbots using python debug mode is affected. Python compiled with release mode is *not* affected and passes the test. Here's an example error on one of the buildbots:
https://buildbot.python.org/all/#/builders/596/builds/354/steps/4/logs/stdio
I can also reproduce this locally. I tracked this issue down after a recursion in AST also caused a stack overflow, see my message here:
https://bugs.python.org/msg395172
TLDR: Windows builds seems to set stack size to 2MB, on *nix it's probably higher (usually 8MB). I suspect the static inline functions are not being inlined in windows debug builds, so every function call adds to the stack. In that message I proposed to increase the stack size on windows but there are some concerns (see msg395177). What do you think?

MSVC by default disables method inlining (/Ob0) when '/Od' is specified on the command line while the optimization options specify '/Ob2'.

Ken Jin: Please open a separated issue for test_exceptions.test_recursion_in_except_handler(). It's not directly related to marking PyObject opaque, as William Pickard explained.
See my notes on the stack size and stack overflow on a recursion error on Windows:
https://pythondev.readthedocs.io/unstable_tests.html#unlimited-recursion 

New changeset 6d518bb3a11f9b16098f45b21a13ebe8f537f045 by Pablo Galindo in branch 'main':
bpo-44348: Revert "bpo-39573: Py_TYPE becomes a static inline function (GH-26493)" (GH-26596)
https://github.com/python/cpython/commit/6d518bb3a11f9b16098f45b21a13ebe8f537f045

See also bpo-44378: "Py_IS_TYPE(): cast discards ‘const’ qualifier from pointer target type".
If Py_TYPE() is converted again to a static inline function which takes a "const PyObject*" type, Py_IS_TYPE() can be modified again at the same time to use Py_TYPE().

New changeset cb15afcccffc6c42cbfb7456ce8db89cd2f77512 by Victor Stinner in branch 'main':
bpo-39573: Py_TYPE becomes a static inline function (GH-28128)
https://github.com/python/cpython/commit/cb15afcccffc6c42cbfb7456ce8db89cd2f77512

> boost https://bugzilla.redhat.com/show_bug.cgi?id=1896382
Fixed by: https://github.com/boostorg/python/commit/500194edb7833d0627ce7a2595fec49d0aae2484 

I checked again the list of broken projects listed previously.
Fixed:
* Cython: https://github.com/cython/cython/commit/d8e93b332fe7d15459433ea74cd29178c03186bd
* immutables: https://github.com/MagicStack/immutables/pull/52
* numpy:
 * https://github.com/numpy/numpy/commit/a96b18e3d4d11be31a321999cda4b795ea9eccaa
 * https://github.com/numpy/numpy/commit/f1671076c80bd972421751f2d48186ee9ac808aa
* pycurl: https://github.com/pycurl/pycurl/commit/e633f9a1ac4df5e249e78c218d5fbbd848219042
* bitarray: https://github.com/ilanschnell/bitarray/pull/109
* mercurial: https://bz.mercurial-scm.org/show_bug.cgi?id=6451
* boost: https://github.com/boostorg/python/commit/500194edb7833d0627ce7a2595fec49d0aae2484
* pyside2: https://bugreports.qt.io/browse/PYSIDE-1436
* breezy: https://bugs.launchpad.net/brz/+bug/1904868
* duplicity: https://git.launchpad.net/duplicity/commit/duplicity/_librsyncmodule.c?id=bbaae91b5ac6ef7e295968e508522884609fbf84
* gobject-introspection: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/243
Fix proposed:
* pybluez: https://github.com/pybluez/pybluez/pull/410
Broken:
* PyPAM
* pygobject3
* pylibacl 
* rdiff-backup

At commit cb15afcccffc6c42cbfb7456ce8db89cd2f77512, I am able to rename PyObject members (to make sure that the structure is not accessed directly), I only had to modify header files:
* Py_REFCNT(), Py_SET_REFCNT()
* Py_INCREF(), Py_DECREF()
* Py_TYPE(), Py_SET_TYPE()
* Py_IS_TYPE()
And just two more C files which corner cases:
* 1 line in Python/specialize.c
* 1 line in Modules/_testcapimodule.c: check_pyobject_forbidden_bytes_is_freed()
--
I did the same with PyVarObject, rename the ob_size member. I had to modify header files:
* Py_SIZE(), Py_SET_SIZE()
But I had to modify the following function of the array module:
static int
array_buffer_getbuf(arrayobject *self, Py_buffer *view, int flags)
{
 ...
 if ((flags & PyBUF_ND)==PyBUF_ND) {
 view->shape = &((PyVarObject*)self)->ob_size;
 }
 ...
 return 0;
}
I'm not sure how to patch this function.
--
This experience doesn't check usage of sizeof(PyObject) and sizeof(PyVarObject) which would break if these structures become opaque. sizeof() issues are listed in previous comments.

Oh and obviously, it's not possible possible to define structures which *include* PyObject or PyVarObject if PyObject and PyVarObject become opaque. Example:
typedef struct {
 PyObject ob_base;
 Py_ssize_t ob_size; /* Number of items in variable part */
} PyVarObject;
This C code requires the PyObject structure to be fully defined (not being opaque).
A new C API and ABI where structures *don't* include PyObject or PyVarObject should be designed to allocate their members "before" the PyObject* pointer value. Something like the current PyGC_Head structure which is excluded from PyObject and stored *before* the "PyObject*" pointer.
Simplified code which allocates memory for an object implementin the GC protocol:
static PyObject *
_PyObject_GC_Malloc(size_t basicsize)
{
 ...
 size_t size = sizeof(PyGC_Head) + basicsize;
 ...
 PyGC_Head *g = (PyGC_Head *)PyObject_Malloc(size);
 ...
 PyObject *op = (PyObject *)(g + 1);
 return op;
}

I changed the issue title to restrict its scope: "[C API] Avoid accessing PyObject and PyVarObject members directly: add Py_SET_TYPE() and Py_IS_TYPE(), disallow Py_TYPE(obj)=type".
Making PyObject and PyVarObject structures opaque is a broader topic which should be splited into sub-issues.
"Py_TYPE(obj)=type;" is now disallowed. I consider that the work of this issue is now completed and I close the issue.
Thanks everyone who help to fix these tedious issues!
You can continue to use this issue if you need my help to adapt your C extensions to Py_SET_TYPE()/Py_SET_SIZE().
See also the upgrade_pythoncapi.py script of the pythoncapi_compat project which helps to port your C extensions without losing support for old Python versions:
https://github.com/pythoncapi/pythoncapi_compat
See also the Py_TYPE() change announcement on the capi-sig list:
https://mail.python.org/archives/list/capi-sig@python.org/thread/WGRLTHTHC32DQTACPPX36TPR2GLJAFRB/ 

I wrote an article about these changes:
https://vstinner.github.io/c-api-abstract-pyobject.html
It elaborates the rationale for making these changes.

> @victor, git bisect tells me the change f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970 caused test_exceptions.ExceptionTests.test_recursion_in_except_handler to stack overflow only on windows debug builds.
FYI this regression was handled last year in bpo-44348 "test_exceptions.ExceptionTests.test_recursion_in_except_handler stack overflow on Windows debug builds" and fixed at 2021年09月07日 by using the trashcan mecanism in the BaseException deallocator function:
New changeset fb305092a5d7894b41f122c1a1117b3abf4c567e by Victor Stinner in branch 'main':
bpo-44348: BaseException deallocator uses trashcan (GH-28190)
https://github.com/python/cpython/commit/fb305092a5d7894b41f122c1a1117b3abf4c567e