Reference Tracking

[Matt Bergin]

Alex Martelli wrote:
> That might cause you problems at termination time, I think.  Also,
> is there any risk that your objects could end up as parts of cycles
> of mutual references?  If so, defining a __del__ makes it impossible
> for the garbage collector to ever reclaim them.

I don't think there's any risk of reference cycles. I should have been 
more clear about what the objects are. I'm trying to write a class to 
wrap MySQLdb and hand out database cursors to worker threads.

> You can try to avoid the periodic scanning overhead by using a
> tricky __del__, or a non-tricky __del__ or weak-reference callback
> for some object that's "packed together with" the object you give
> out (keeping the latter alive in a per-class container anyway).  A
> radically different and far cleaner approach would be to specify
> a way (e.g. a method) for the using-code to say "I'm finished with
> this object, reuse it freely from now on" -- no black magic at all
> (of course, perhaps marginally smaller convenience for the using
> code, but it's not all that bad to ensure a finalization method
> gets explicitly called, IMHO).

I'm just worried that if an exception occurs in a thread then the cursor 
will never be returned, using the 'no black magic' method which appeals 
to me the most. Could I prevent this by careful use of try: finally?

-- 
Matt Bergin