Le mer. 27 févr. 2019 à 19:38, Neil Schemenauer email@example.com a écrit :
I think the PyHandle idea has the best chance of producing a good end result. I suspect PEP C doesn't go far enough to solve the problems for alternative Python implementations. They really want PyObject to be an opaque handle-like object. Trying to make the existing C-API work like that seems like a nearly impossible task.
In https://pythoncapi.readthedocs.io/ I proposed solutions to get a smooth transition towards a better C API without starting from scratch nor breaking backward compatibility.
I agree that it doesn't solve all problems, and that CPython would be the first one to benefit from this.
That's why I proposed to split the discussions into multiple PEPs.
The PyHandle layer can be implemented as a separate project. That gives the freedom to tinker without upsetting people. It will take some missteps and revisions until the API becomes polished. You don't want to make those mistakes inside the CPython repo.
I proposed to add a new opt-in C API (basically, the current C API with minor changes) directly in the master branch of Python, but I have been asked to write a PEP for that. It would be the PEP C.
Another option would be to work in a fork of CPython. I already did that: https://github.com/pythoncapi/cpython
That's not a good long-term solution. If we decide to enhance the API and add a new opt-in API, it should be easy to use/experiment it. There is always the problem of the critical mass to make a project successful.
As the PyHandle API evolves, I would imagine we would have a lot of ideas about what PEP C should entail. Ideally the APIs defined by PEP C would be the ones you need to implement PyHandle for CPython. I think trying to do PEP C before PEP D is the wrong way around.
An initial goal would be to make the PyHandle layer be a replacement for the limited API. I.e. make it so that any extension currently using the limited API could switch to it.
Even if the PEP D makes your applications 10x faster, I don't believe that we will ever be able to get ride of the current C API. Again, see the transition from Python 2 to Python 3. Ten years later, some people are just discussing how to start to migrate this code base. And a lot of code will stay at Python 2 forever.
That's why I consider that we need to work on PEP C and PEP D in parallel, but also on PEP A to show the other existing solutions ;-)
I'm not sure about the exact timeline. We can draft a PEP C right now, but wait until we get enough feedback to take a decision. We might wait until PEP D made progress if you prefer.
Night gathers, and now my watch begins. It shall not end until my death.