On 15.06.2020 17:15, Petr Viktorin wrote:
On 2020-06-15 17:05, M.-A. Lemburg wrote:
On 15.06.2020 16:35, Matti Picus wrote:
On 6/15/20 2:47 PM, M.-A. Lemburg wrote:
FWIW: I don't see problems for other implementations to provide the above API, but perhaps I'm missing something.
The problem is that there is no pure python equivalent, and the other implementations have to spend quite a lot of effort mimicking the obscure corners of the C-API. In my opinion, any public C-API function should mirror a python equivalent. Python has no overt language specification, but I would hope one of the underlying principles would be to expose the same paradigms in python and C.
That's an odd request. We're talking about the C API here, not the Python API. Of course, the C API will have different requirements than the Python one, simply because it's C.
The request is to not extend the C-API not only with a new function, but also with a notion of an object that's allocated using PyObject_New but not in the interpreter's "management scope".
Perhaps I wasn't clear: the object is already allocated and managed by Python. The error happens in the initializer and the API is meant to signal: please remove this object from the management scope, since I have already dealt with the cleanup.
The call is needed to let the CPython implementation know that it should unlink the object at the moment, but this could be changed in the future. Other implementations could use it for different things.
It's really just a way to tell Python: please remove this object from your management scope.
There is no Python equivalent, since the low level memory management happens entirely in C.
An error handler in the constructor will know which parts have been initialized and which not, e.g. say an object needs to configure a number of objects in a 3rd party library and one of these steps fails. The constructor can then undo the steps it has taken up to the point where the error occurred.
This can be handled in __del__ as well by setting flags to 0 and pointers to NULL values when calling __new__ (or simply calling memset(..0) ), then filling them out in __init__ one at a time. Any 0-ed values indicate that the __del__ function does not have to undo the initialization/allocation of that value.
Yes, I know, but think of an object which doesn't otherwise require such a flag. You'd increase the memory footprint just to be able to do proper error handling.
Do we have any evidence such objects exist in the real world? In other words, is this enough of a problem that it needs new public API?
Well, if you search on Github, you find some 18k hits. Many are from forks of the Python source code, but there are also a number of hits in stackless, nuitka, pyuv, PyPy's cpyext and numpy from a quick inspection.
Most uses call the API to prevent segfaults in debug builds (which use can use object tracing -- not sure whether they always do).
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jun 15 2020)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/