__del__ problem - more details provided. still stumped though.

[Greg Ewing]

Warren Postma wrote:
> 
> class DBPtr :
>     def __init__(self,this):
>         self.this = this
>         self.thisown = 0
>     def __del__(self):
>         if self.thisown == 1 :
>             dbc.delete_DB(self.this)  # appears some exceptions being raised
> here.

That's a SWIG-generated shadow class! I had the very
same kind of problem when I used SWIG to wrap some
Xlib functions. What is boils down to is that:

*** SWIG generates buggy __del__ methods! ***

They don't protect themselves against the loss of
module-level names at finalisation time. In the
example above, if 'dbc' in the current module, or
'delete_DB' in the dbc module, has been clobbered
by Py_Finalize before the __del__ method is called,
trouble will result.

My solution was to write my own shadow classes rather
than relying on SWIG (I had other reasons to do this
in any case). In your case, you could try editing the
__del__ method to say

      def __del__(self, delete_DB = dbc.delete_DB):
         if self.thisown == 1 :
             delete_DB(self.this)

and similarly in any other __del__ methods that
are lying about.

-- 
Greg Ewing, Computer Science Dept,
+--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+