homepage

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

AltStyle によって変換されたページ (->オリジナル) /