Author vstinner
Recipients Mark.Shannon, brett.cannon, dino.viehland, eric.snow, fabioz, gregory.p.smith, lukasz.langa, phsilva, vstinner
Date 2020-03-12.17:05:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1584032745.05.0.917722062603.issue38500@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2020-03-12 17:05:45vstinnersetrecipients: + vstinner, brett.cannon, gregory.p.smith, fabioz, phsilva, dino.viehland, lukasz.langa, Mark.Shannon, eric.snow
2020-03-12 17:05:45vstinnersetmessageid: <1584032745.05.0.917722062603.issue38500@roundup.psfhosted.org>
2020-03-12 17:05:45vstinnerlinkissue38500 messages
2020-03-12 17:05:44vstinnercreate