On Wed, Feb 27, 2019 at 10:39 AM Neil Schemenauer <nas-python@arctrix.com> wrote:
On 2019-02-22, Victor Stinner wrote:
== PEP D: Completely new C API ==
Well, that's the obvious alternative to PEP C.
Armin Rigo's PyHandle idea may be a good start? https://pythoncapi.readthedocs.io/pyhandle.html
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.
+1
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.
+1
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.
I guess it depends on what "enhancements" people are thinking about. But there definitely is a chance that PEP D can help inform PEP C.
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.
As long as people don't think it's a 1:1 correlation of the APIs but the idea is that extensions using the limited API should be able to use the PEP D API with a rewrite does make sense as a good goal to me.