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:55 | vstinner | set | recipients: + vstinner, nascheme, ronaldoussoren, serhiy.storchaka, steve.dower, hroncok, corona10, ZackerySpytz, WildCard65, shihai1991, petdance |
| 2020年11月18日 14:24:55 | vstinner | set | messageid: <1605709495.47.0.774958670824.issue39573@roundup.psfhosted.org> |
| 2020年11月18日 14:24:55 | vstinner | link | issue39573 messages |
| 2020年11月18日 14:24:54 | vstinner | create | |