[Python-Dev] PEP 442 clarification for type hierarchies

Antoine Pitrou solipsis at pitrou.net
Mon Aug 5 20:51:09 CEST 2013


On Sun, 04 Aug 2013 09:23:41 +0200
Stefan Behnel <stefan_ml at behnel.de> wrote:
> I'm currently catching up on PEP 442, which managed to fly completely below
> my radar so far. It's a really helpful change that could end up fixing a
> major usability problem that Cython was suffering from: user provided
> deallocation code now has a safe execution environment (well, at least in
> Py3.4+). That makes Cython a prime candidate for testing this, and I've
> just started to migrate the implementation.

That's great to hear. "Safe execution environment" for finalization
code is exactly what the PEP is about.

> One thing that I found to be missing from the PEP is inheritance handling.
> The current implementation doesn't seem to care about base types at all, so
> it appears to be the responsibility of the type to call its super type
> finalisation function. Is that really intended?

Yes, it is intended that users have to call super().__del__() in their
__del__ implementation, if they want to call the upper-level finalizer.
This is exactly the same as in __init__() and (most?) other special

> Another bit is the exception handling. According to the documentation,
> tp_finalize() is supposed to first save the current exception state, then
> do the cleanup, then call WriteUnraisable() if necessary, then restore the
> exception state.
> http://docs.python.org/3.4/c-api/typeobj.html#PyTypeObject.tp_finalize
> Is there a reason why this is left to the user implementation, rather than
> doing it generically right in PyObject_CallFinalizer() ? That would also
> make it more efficient to call through the super type hierarchy, I guess. I
> don't see a need to repeat this exception state swapping at each level.

I didn't give much thought to this detail. Originally I was simply
copying this bit of semantics from tp_dealloc and tp_del, but indeed we
could do better. Do you want to open an issue about it?



More information about the Python-Dev mailing list