On Tue, 7 Dec 2021 15:39:25 +0100
Petr Viktorin
On 30. 11. 21 19:52, Victor Stinner wrote:
On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum
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.