Extract of the Backward Compatibility section of the PEP: "This change does not follow the PEP 387 deprecation process. There is no known way to emit a deprecation warning only when a macro is used as a l-value, but not when it's used differently (ex: as a r-value)."
Victor On Tue, Dec 7, 2021 at 4:41 PM 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/ -- 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/YA3RN7Q2NHTRDMWI7Z6VWUZIAJ4JCD2D/ Code of Conduct: http://python.org/psf/codeofconduct/
