An idea for unmaintained incompatible C extensions is to update the C code when a C extension is installed, as part of the build process. For example, replace "Py_TYPE(obj) = new_type" with "Py_SET_TYPE(obj, new_type)".
Something similar to the old "2to3" option of setuptools. The upgrade_pythoncapi.py of the pythoncapi_compat project is already a partial implementation of idea: it can update the C code, but it's not integrated in tools like setuptools. It's just an idea, a full implementation should be designed and written. Victor On Tue, Dec 7, 2021 at 5:56 PM Joao S. O. Bueno <jsbu...@python.org.br> wrote: > > Sorry for stepping in - but I am seeing too many arguments in favour > of the rules because "they are the rules", and just Victor arguing with > what is met in the "real world". > > But if this update can be done by a simple search/replace on the C source of > projects, > I can only perceive two scenarios this will affect: well maintained projects, > for which it is fixable in minutes, and stale packages, no longer released > that "happen to work" when someone downloads and builds for new > Python versions. In these cases, the build will fail. If the person trying > the build can't fix it, but can take the error to a proper, or high > visibility, > forum, someone will be able to come to the fix, leading to renewed > visibility for the otherwise stale package. > > > > On Tue, 7 Dec 2021 at 12:40, Antoine Pitrou <anto...@python.org> wrote: >> >> On Tue, 7 Dec 2021 15:39:25 +0100 >> Petr Viktorin <encu...@gmail.com> wrote: >> >> > On 30. 11. 21 19:52, Victor Stinner wrote: >> > > On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum <gu...@python.org> >> > > wrote: >> > >> How about *not* asking for an exception and just following the PEP 387 >> > >> process? Is that really too burdensome? >> > > >> > > The Backward Compatibility section gives an explanation: >> > > >> > > "This change does not follow the PEP 387 deprecation process. There is no >> > > known way to emit a deprecation warning when a macro is used as a >> > > l-value, but not when it's used differently (ex: r-value)." >> > > >> > > Apart of compiler warnings, one way to implement the PEP 387 >> > > "deprecation process" would be to announce the change in two "What's >> > > New in Python 3.X?" documents. But I expect that it will not be >> > > efficient. Extract of the Rejected Idea section: >> > > >> > > "(...) only few developers read the documentation, and only a minority >> > > is tracking changes of the Python C API documentation." >> > > >> > > In my experience, even if a DeprecationWarning is emitted at runtime, >> > > developers miss or ignore it. See the recent "[Python-Dev] Do we need >> > > to remove everything that's deprecated?" discussion and complains >> > > about recent removal of deprecated features, like: >> > > >> > > * collections.MutableMapping was deprecated for 7 Python versions >> > > (deprecated in 3.3) -- removed in 3.9 alpha, reverted in 3.9 beta, >> > > removed again in 3.11 >> > > * the "U" open() flag was deprecated for 10 Python versions >> > > (deprecated in 3.0) -- removed in 3.9 alpha, reverted in 3.9 beta, >> > > removed again in 3.11 >> > > >> > > For this specific PEP changes, I consider that the number of impacted >> > > projects is low enough to skip a deprecation process: only 4 projects >> > > are known to be impacted. One year ago (Python 3.10), 16 were >> > > impacted, and 12 have already been updated in the meanwhile. I'm >> > > talking especially about Py_TYPE() and Py_SIZE() changes which, again, >> > > has been approved by the Steering Council. >> > >> > >> > The current version of the PEP looks nice, but I don't think the >> > rationale is strong enough. >> > I believe we should: >> > - Mark the l-value usage as deprecated in the docs, >> > - And then do nothing until we find an actual case where this issue >> > blocks development (or is actively dangerous for users). >> >> Is there a way to emit a compilation warning when those macros are used >> as l-values? Even if only enabled on some compilers. >> >> Regards >> >> Antoine. >> >> >> _______________________________________________ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/YMMRRVVYIS6PJR3WTKLYDFY3XJ3UAKW3/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/WNTZZYLT3VK6REJ3BEBVGNDGZCIXWFCA/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FEZN6IZO34IPYY52G5UDVIODT6YB5WI6/ Code of Conduct: http://python.org/psf/codeofconduct/
