STINNER Victor <vstin...@python.org> added the comment:
For me, the *short term* goal is to find a way to limit the number of broken C extension module while we modify the C API to make it more opaque. We cannot reach all goals at once (opaque C API, subinterpreter, more optimizations, etc). We have to move step by step. For me it's ok to deprecate or even remove PyInterpreterState_SetEvalFrameFunc() later, once we will have a good reason for that. I'm also ok with having an alternative Python implementation which doesn't support PyInterpreterState_SetEvalFrameFunc(). Users would be able to make a choice: faster Python without PyInterpreterState_SetEvalFrameFunc(), or regular "slow" Python with PyInterpreterState_SetEvalFrameFunc(). That's part of my larger https://pythoncapi.readthedocs.io/ goal: the ability to use different Python "runtimes". >From what I understood, to be able to provide multiple Python runtimes, we >have first to "fix" the C API. The HPy project is another approach to this >problem. Making the C API opaque makes CPython closer to this goal. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38500> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
