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.  



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/YMMRRVVYIS6PJR3WTKLYDFY3XJ3UAKW3/
Code of Conduct: http://python.org/psf/codeofconduct/