Author pitrou
Recipients kristjan.jonsson, pitrou, tim.peters
Date 2010-07-02.14:04:49
SpamBayes Score 0.0148674
Marked as misclassified No
Message-id <1278079487.3201.8.camel@localhost.localdomain>
In-reply-to <1278079153.27.0.59964514373.issue9141@psf.upfronthosting.co.za>
Content
> 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.
History
Date User Action Args
2010-07-02 14:04:51pitrousetrecipients: + pitrou, tim.peters, kristjan.jonsson
2010-07-02 14:04:50pitroulinkissue9141 messages
2010-07-02 14:04:49pitroucreate