__del__ is not a good way to handle this. When exiting, some things can
fail unexpectedly causing spurious errors (like the print oddity you
describe). I ran into this using MySQLdb.

Check out the Quixote Wiki entry on this topic:

http://www.quixote.ca/qx/ReusingConnections

An explicit cleanup handler plus a finally: clause does the trick.

Dave

On Oct 19, 2004, at 2:24 AM, Tim Golden wrote:

> [Dave Kuhlman]
>
> [... snip re subclassing Publisher and adding __del__ ...]
>
> | Of course, you will want to put a debugging message in the __del__
>  | method to make sure that it is being called.  As I recall, there is
>  | a bit of weirdness about the __del__ method.  A print statement
> | placed directly in the __del__ method works.  But, a call to
>  | another function containing a print statement does not.  At least,
>  | that's what I recall.
>
> Well one caveat about __del__ is that there's no guarantee that
> it will be called, although it generally is in my experience.
> Quote from library ref: "It is not guaranteed that __del__()
> methods are called for objects that still exist when the
> interpreter exits." I believe that a good alternative is
>  the sys.exitfunc / atexit module approach, so long as you can make
>  it work with your object scopes etc.
>
> (I realise that the suggestion about a print statement probably
>  reflected this uncertainty but I thought I'd just make it
>  explicit.)
>
> TJG
>
> _______________________________________________________________________
> _
> This e-mail has been scanned for all viruses by Star. The
>  service is powered by MessageLabs. For more information on a proactive
>  anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> _______________________________________________________________________
> _
> _______________________________________________
> Quixote-users mailing list
>  Quixote-users@mems-exchange.org
>  http://mail.mems-exchange.org/mailman/listinfo/quixote-users