__del__ problem - more details provided. still stumped though.

[Jeff Senn]

"Gordon McMillan" <gmcm at hypernet.com> writes:
> Warren Postma wrote:
...
> >     def __del__(self):
...
> The problem is that the Py_Finalize logic has a real hard time 
> knowing in what order to zap things. By the time this __del__ 
> runs, the dbc module has already been zapped. Squirrelling 
> away a reference in the method definition will ensure it's 
> existence.  In general, a __del__ method (or anything called 
> from a __del__ method) cannot rely on any references outside 
> the object unless it uses this trick.

Yes -- a number of folks who come from (non-Python) "OO" languages
seem to fall into this particular trap.  Variables assigned in the
module look a lot like things that would be called "static (class)
variables" in other languages -- the fact is, that instances of classes
in Python can outlive the module in which the class was defined. So
this pattern of using "module variables" as "(class) statics" is a
dubious thing in Python -- it tends to work only because people don't
tend to write code that cleans up modules... it will show up other
places then __del__ if you try that (anyone tried calling reload()
aggressively? e.g. in a dynamic development env...)

If this is not in docs somewhere with an example it probably should
be...

-- 
-Jas