On 18. 01. 22 9:30, Victor Stinner wrote:
Hi,
I made the following changes to the PEP since the version 1 (November 30):
* Elaborate the HPy section and add a new "Relationship with the HPy
project" section
* Elaborate which projects are impacted and which changes are needed
* Remove the PyPy section
The PEP can be read online:
https://python.github.io/peps/ep-0674/
And you can find the plain text below.
Victor
PEP: 674
Title: Disallow using macros as l-value
The current PEP is named "Disallow using Py_TYPE() and Py_SIZE() macros
as l-values", which is misleading: it proposes to change 65 macros.
Author: Victor Stinner <vstin...@python.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30-Nov-2021
Python-Version: 3.11
Abstract
========
Incompatible C API change disallowing using macros as l-value to:
* Allow evolving CPython internals;
In the current PEP, this is now "Allow evolving CPython internals
(change the PyObject structure);"
But that's not really true: the PyObject won't become changeable if the
PEP is accepted, since `ob_type` is part of the stable ABI, and direct
access to this field is compiled into existing extensions that use the
stable ABI.
This PEP alone won't really help nogil.
* Ease the C API implementation on other Python implementation;
* Help migrating existing C extensions to the HPy API.
On the PyPI top 5000 projects, only 14 projects (0.3%) are affected by 4
macro changes. Moreover, 24 projects just have to regenerate their
Cython code to use ``Py_SET_TYPE()``.
This data was gathered in 2022.
Since this change was made in 2020 and then reverted because it broke
too many projects (which were presumably notified of the breakage and
had 2 years to update), the 0.3% is misleading. It is a measure of the
current porting effort, not an estimate of the chance of a given project
being affected.
In practice, the majority of affected projects only have to make two
changes:
* Replace ``Py_TYPE(obj) = new_type;``
with ``Py_SET_TYPE(obj, new_type);``.
* Replace ``Py_SIZE(obj) = new_size;``
with ``Py_SET_SIZE(obj, new_size);``.
I'll post my counterproposal, please tell me what's wrong with it (and
ideally add it to Rejected ideas):
- document that these macros should not be used as l-values
- and that's it for CPython.
When this is done, interested people can try compiling projects with
HPy, and send fixes to various projects. The above documentation should
be a strong reason to accept the PRs. And finding the issue is
relatively easy -- compile with modified CPython headers.
Meanwhile, projects that don't care about HPy (yet), or projects that
want to keep working with minimum maintenance, can do the change on
their own timeline.
If and when the time comes and the proposed change is actually
beneficial to all/most users in the short term (for example it is needed
for some major performance improvement or nogil), or we can make it
opt-in, or it becomes one of a few things that prevent CPython from
switching to HPy, then we can do the change. Within one release, even.
The PEP doesn't propose any deprecation period because it's impractical
to produce compiler warnings; IMO we should handle this by having a long
"docs-only deprecation" period, rather than not having a deprecation
period at all.
_______________________________________________
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/TEKRMXAKLFTWSZBFOXIK35TAKWMWQISA/
Code of Conduct: http://python.org/psf/codeofconduct/
