[Python-Dev] PEP 442 clarification for type hierarchies
Stefan Behnel
stefan_ml at behnel.de
Sun Aug 4 09:23:41 CEST 2013
Hi,
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.
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? Couldn't the super type
call chain be made a part of the protocol?
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.
So, essentially, I'm wondering whether PyObject_CallFinalizer() couldn't
just set up the execution environment and then call all finalisers of the
type hierarchy in bottom-up order.
Stefan
More information about the Python-Dev
mailing list