Le mar. 5 mars 2019 à 07:51, Carl Shapiro <carl.shapiro@gmail.com> a écrit :
On Fri, Mar 1, 2019 at 10:11 AM Neil Schemenauer <nas-python@arctrix.com> wrote:
Is this an argument for not introducing a PyHandle data type? Do you think it is better just to make PyObject work as handles?
To answer your question somewhat obliquely, I believe that it is possible to make the C-API more amenable to alternative Python implementations with incremental changes to the C-API that could be absorbed by third-party code over a series of releases. I also believe that improving PyObject* does not preclude providing a better abstraction like a PyHandle. I suspect many of the API work needed to make PyObject* better would be required to make even PyHandle possible.
IMHO we should attempt both approaches:
Make PyObject structure "more" opaque. Either make it fully opaque and break the Python world in a flag data (haha, that would be funny!), or add a new opt-in C API (using a C #define or whatever). I worked on the opt-in approach. This approach doesn't work with old Python versions which cannot be modified anymore, it cannot start before Python 3.8.
Add a fully new PyHandle API which would be compatible with Python 2.7-3.8.
In parallel, more and more C API changes are pushed in Python 3.8 to make some structures opaque (PyInterpreterState). That's the first obvious option that I called "break the world", but the most risky.
It's way too early to bet which approach will work in the long term.
To be even more clear, all approaches have exactly the same goal: having a more opaque C API to hide as much implementation details as possible. The long term goal should to hide "all" implementation details. I let you try to define what are implementation details or not. Is CPython GC implementation an implementation detail (destroy an object as soon as its ref count reach zero)? ... These are hard questions :-)
PyPy knows better than me than CPython is full of subtle implementation details. For example, I was very surprised to learn that Python creates a ".0" local variable to list comprehensions :)
[locals() for i in range(1)] [{'.0': <range_iterator object at 0x7fcf3bf29300>, 'i': 0}]
Fixing the C API cannot be done at once. It must be a process.
Victor