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 <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/ > > > _______________________________________________ > 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/WNTZZYLT3VK6REJ3BEBVGNDGZCIXWFCA/ > Code of Conduct: http://python.org/psf/codeofconduct/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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/B5NPZYLOP5TUHHG3VKNRAWJXIHMYY5C2/ Code of Conduct: http://python.org/psf/codeofconduct/
