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. Victor