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).
Specifically, for each of the Rationale parts:
## Using a macro as a l-value
The practice was often discouraged (e.g. by GET in many of the names),
or even relatively widely and successfully used (e.g. Py_TYPE before
Python 3.9).
If we would deprecate using Py_REFCNT as l-value in the docs, but wait
with the conversion until it was *actually* needed, we would not lose
anything:
- Users would *still* have no period of visible compiler warnings or
DeprecationWarning.
- There would be more time for users to react to the documentation
warning. Or even come up with a linter, or try compiling their favorite
extensions with HPy/nogil and fixing the issues *on their own schedule*.
## CPython nogil fork
In CPython, we cannot change structs that are part of the stable ABI --
such as PyObject.ob_refcnt. IMO, getting rid of the macros that access
ob_refcnt is a relatively small part of this issue.
AFAICS, the technical change is trivial compared to nogil, and can be
easily made in the nogil fork -- if it is actually necessary in the end.
## HPy project
There is no reason for "Searching and replacing Py_SET_SIZE()".
If this change was not made, and Py_SIZE was semi-mechanically replaced
by HPy_Length(), then misuses of Py_SIZE (using is as l-value) can be
detected very easily: just compile against HPy.
And if the autoreplacer is smart enough to see when it should use
HPyTupleBuilder/HPyListBuilder, then it can surely see when Py_SIZE is
(mis)used as l-value!
There will always be some changes necessary when porting extensions to HPy.
CPython should definitely indicate what the best practice is, so that
HPY adopters have an easy time convincing projects to take their pull
requests -- but it should not break code for people who don't care about
HPy yet.
## GraalVM Python
This PEP is not enough to get rid of wrappers in GraalVM, yet it forces
users of CPython to adapt. Is it a part of a *plan* to remove wrappers,
or just a minor step in what looks like the general direction?
I do agree this PEP looks like a good step towards a long-term goal. But
even so, it should be made when it *actually benefits* existing users,
or allows some concrete good thing -- an optimization, a more
maintainable implementation, something that outweighs the need for churn
in code that worked up to now.
Overall, the Rationale seems hollow to me. It's breaking existing code
-- however bad that code is -- in the name of ideals rather than
concrete improvements.
Until disallowing macros as l-values allows concrete improvements in
CPython, it should be the job of linters.
FWIW, I do encourage alternative implementations to just not support
l-value macros. There are only few projects doing this, and the fix is
often (but not always!) easy. This should be a very small part of
porting something to a different Python implementation (but I could
definitely be wrong here, please correct me).
_______________________________________________
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/RRX7LV4NDG4Z76NG2FPWI44AGMRQANIE/
Code of Conduct: http://python.org/psf/codeofconduct/
