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 <jsbueno@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 <antoine@python.org> wrote:
On Tue, 7 Dec 2021 15:39:25 +0100 Petr Viktorin <encukou@gmail.com> wrote:
On 30. 11. 21 19:52, Victor Stinner wrote:
On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum <guido@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-leave@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/YMMRRVVY... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/WNTZZYLT... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.