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/
