On Tue, Oct 5, 2021 at 12:40 PM Petr Viktorin <encukou@gmail.com> wrote:
The reason I asked is that this formally needs SC exception to the backwards compatibility policy. I can apply for the exception if you don't want to, but I'd like to give some good arguments for it -- and while I agree with most of what's in these documents, I don't think making this particular change now is good.
To summarize how I feel: third-party projects.
- CPython and third-party projects can port to Py_SET_TYPE now.
- Experiments (like tagged pointers) can be tried with only the ported
It's not about experimental things. It's about *preparing* the C API to completely abstract access to Python objects, to prevent Python implementations other than CPython to have to emulate the whole CPython implementation as PyPy cpyext does. Emulating CPython implementation is inefficient.
CPython should also benefit from these changes. Today, CPython is stuck at design choices made 30 years ago. If the C API fully abstract access to Python objects, as the HPy project does, it becomes possible to make significant optimizations in CPython (without losing support for 3rd party C extensions).
In short, this change is required to optimize CPython.
I gave more details about these problems in two PEPs:
https://www.python.org/dev/peps/pep-0620/ and https://mail.python.org/archives/list/python-dev@python.org/thread/RA7Q4JAUE...
Victor
- This is exactly the kind of mandatory code churn that makes Python look bad for users that wrote an extension and want it to work.
- I can see no downside to changing this later, when it brings actual benefit for users.
But, FWIW, I'd support making the change in the 3.11 limited API: if a third-party project changes the Py_LIMITED_API #define, they should be able to modernize their code as well. Same for Py_BUILD_CORE -- we can be stricter in code we control.
-- Night gathers, and now my watch begins. It shall not end until my death.