This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients WildCard65, ZackerySpytz, corona10, hroncok, nascheme, petdance, ronaldoussoren, serhiy.storchaka, shihai1991, steve.dower, vstinner
Date 2020-11-18.14:24:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1605709495.47.0.774958670824.issue39573@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2020-11-18 14:24:55vstinnersetrecipients: + vstinner, nascheme, ronaldoussoren, serhiy.storchaka, steve.dower, hroncok, corona10, ZackerySpytz, WildCard65, shihai1991, petdance
2020-11-18 14:24:55vstinnersetmessageid: <1605709495.47.0.774958670824.issue39573@roundup.psfhosted.org>
2020-11-18 14:24:55vstinnerlinkissue39573 messages
2020-11-18 14:24:54vstinnercreate