On Tue, 2021-12-07 at 13:54 -0300, Joao S. O. Bueno 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.
The problem are really less-maintained projects that may miss it or take very long to react. And that may be very frustrating for their users (who will not have a work-around beyond patching the project!). So the question is whether these are so few users, that it is OK to break them (even many bug fixes will break someone, after all). The other consideration may be that documenting the change for a 1-2 years may achieve almost nothing except frustrating Victor ;). One thing we once did in NumPy (for a runtime problem), was to intentionally break everyone at pre-release/dev time to point out what code needed fixing. Then flip the switch back at release time as to not break production. After a long enough time we enabled it for release mode. Not saying that it was nice, but it was the only alternative would have been to never fix it. A similar switch could be worthwhile if it helps Victor with experimenting on the dev-branch or reach a useful amount of projects. Of course, I am not sure it would do either... Cheers, Sebastian
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/