Antoine Pitrou <pit...@free.fr> added the comment: > 1. The use case is any C extension that may need to run non-trivial > code when being deleted, but where this can not be statically known.
tp_del is IMO a bad place to do it. I'd recommend tp_dealloc instead, precisely so that you don't end up with uncollectable objects tied to internal OS structures or other non-trivial resources. (also, tp_del seems to have problems with subclassing. I don't remember the specifics) > 3. This code is only invoked for garbage deemed collectable. As such > it is not on any critical path, most gc collections don't actually > find any garbage. The cost of a few extra indirect function calls is > likely to drown in the memory allocator overhead when the objects are > released. Ok. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9141> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
