On Mon, Feb 7, 2022 at 2:08 PM Petr Viktorin <encu...@gmail.com> wrote: > Basically, instead of "We'll remove this API now because it prevents > moving to a hypothetical moving garbage collector", it should be "Here > is a moving garbage collector that speeds Python up by 30%, but to add > it we need to remove these 30 deprecated APIs". The deprecation can be > proactive, but not the removal.
PEP 674 gives 3 concrete examples of issues already affecting the CPython nogil fork, HPy and GraalPython. They are not hypothetical. CPython is also affected by these issues, but the benefits of PEP 674 (alone) are too indirect, so I chose to avoid mentioning CPython issues directly, to avoid confusion. It's possible to workaround them: more or less copy/paste CPython inefficient code, as PyPy did years ago. The problem is that the workaround is inefficient and so PyPy cpyext remains slow. Well, HPy address the cpyext performance problem for PyPy and GraalPython ;-) I don't think that the question is if there is a real problem or not. The question is what's the best migration plan to move existing C extensions towards a better API which don't suffer from these problems. Once 95% of C extensions will use the limited C API, we would still not be able to change Python internals, because of the 5% remaining C extensions which are stuck at the legacy C API. Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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/INQP74MGMUVSKCO7A7NCXDNML646SHRL/ Code of Conduct: http://python.org/psf/codeofconduct/
