Hello,
Thank you for submitting PEP 674 -- Disallow using macros as l-values!
For Py_TYPE, we respect the previous steering council's decision:
https://github.com/python/steering-council/issues/79
The Py_TYPE macro can be changed as proposed in 3.11. However, the old
SC explicitly noted that the exception only applies to Py_SET_TYPE, and
that in general, there should be a deprecation notice in some way or form.
After deliberating the proposed changes, the SC agrees that they will
make CPython better. However, we are not convinced that they should be
made *right now*. We see no reason to rush. We would like to ask you to
rework the PEP to reflect these suggestions.
It is not feasible to provide visible deprecation warnings for the
proposed changes. We feel that this is not a good reason to skip the
deprecation process entirely. Quite the opposite: if we need to skip a
step, we should move even more carefully than usual.
We suggest the following process:
First, add notices to any documentation that using the macro as a
l-value is a deprecated, CPython-specific detail. It should be clear
that the only reason this usage is allowed is for backwards
compatibility, and that alternate implementations of the C API are free
to not allow this.
Then, wait until all supported versions of CPython include any relevant
replacement macros such as Py_SET_SIZE. (This doesn't mean adding "set"
variants to all the changed macros -- just to those few where setting
can be useful and safe.)
With the current schedule, this means waiting until Python 3.14, which
is planned for October 2024, when Python 3.8 will reach end-of-life.
The SC can give an exception to shorten the wait for specific macros, if
there is a real benefit to it. (For example: the nogil branch should
include any necessary changes, and they should be approved and merged
with nogil itself).
Finally, ask the new Steering Council to make the change and finally
disallow using the macros as l-values. If there's no negative feedback
or unexpected downsides, we hope that the future SC will summarily approve.
Hopefully, this strategy will also work for PyDescr_NAME and other
macros that were left out of the PEP for now.
Additionally, consider making the change in the 3.11 version of the
limited API. This version is opt-in, so users are free to do the switch
when it is convenient for them. Also, it would allow early testing and
review of the changes.
Further discussion about this should happen on python-dev, like usual.
- Petr, on behalf of the Steering Council
_______________________________________________
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/CV6KWDRHV5WP6TIDK3Z46PW7HNSHYOWG/
Code of Conduct: http://python.org/psf/codeofconduct/
