example :
"dosomething.py"
import persutils
class myclass :
def __init__(self...) :
.
.
.
def __del__(self) :
self.unload()
.
.
def unload(self) :
persutils.freeresources(self.handle)
.
.
.
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
It's not really a bug, it's a consequence of the "aggressive"
cleanup mechanism added in 1.5.1.
> I think that the imported should be unloaded only after the
> destructor for the class finishes executing.
Well, it isn't exactly trivial for Python to know what you
want to do in the destructor... so you have to keep your
own reference to the module in question. try:
def unload(self, free=persutils.freeresources) :
free(self.handle)
Cheers /F
http://www.pythonware.com/people/fredrik
> I am using Python-1.5.1 on Windows NT. I have a class for which I
> have defined a destructor function __del__.
This stuff is always tricky. I have never found that the __del__
method does what I want, but maybe that's just me.
> I have imported a module
> say 'persutils'. While using the class object when the destructor
> gets called, the module 'persutils' is not loaded anymore. So in the
> destructor if I have to call some function from 'persutils', I have
> to import it again. It looks like a bug. I think that the imported
> should be unloaded only after the destructor for the class finishes
> executing. Please correct me if I am wrong.
Bluntly:
What are you talking about?
It would help enormously if you could include
a) *complete* code that exhibits the problem
b) the traceback or other error output of the interpreter when things
go wrong.
Recontructing from your skeleton, I have in file persutils.py
------------------------------------------------
def freeresources(handle):
print "handle <", handle, "> freed!"
------------------------------------------------
and in dosomething.py
------------------------------------------------
import persutils
class myclass:
def __init__(self):
self.handle=2
def __del__(self):
self.unload()
def unload(self):
persutils.freeresources(self.handle)
------------------------------------------------
and in exhibit.py:
------------------------------------------------
import dosomething
e=dosomething.myclass()
del e
f=dosomething.myclass()
------------------------------------------------
typing 'python exhibit.py' gets the output
------------------------------------------------
handle < 2 > freed!
handle < 2 > freed!
------------------------------------------------
which is what I expected.
> Amod
>
Mind you, I have an extremely new Python 1.5b2, so it possible it was
a bug that's now been fixed.
HTH
--
Michael Hudson
Jesus College
Cambridge CB5 8BL
mw...@cam.ac.uk
the modules aren't unloaded; once imported, "persutils" is
a global variable in your module's namespace, and that variable
is before Python gets around to destroy your object.
see the thread starting with
http://www.dejanews.com/getdoc.xp?AN=387099606
for more details and workarounds
Maybe you got it wrong in some way, thinking it's a
destructor you can call explicitly.
Maybe you think it's called when you do
del obj
but that's not true. del just removes the name "obj" from
the actual namespace. The object behind "obj"
will be deleted exactly if "obj" was the only name
bound to it. In this case, __del__ will be called.
__del__ will not be called and the object not be removed
when some other reference still points to it.
Check out the docs concerning del and reference counting
if this explanation doesn't help you. I hope that in the
future __del__ will do what you want it to ;-)
--
i.A. EVM/HEI
Where did you want to go again?
No, I know what __del__ is, and when it's called. Maybe I should have
phrased that "I have never found myself in a situation where writing a
__del__ method would improve my quality of life." I always end up
doing something else.
> Maybe you think it's called when you do
> del obj
> but that's not true. del just removes the name "obj" from
> the actual namespace. The object behind "obj"
> will be deleted exactly if "obj" was the only name
> bound to it. In this case, __del__ will be called.
> __del__ will not be called and the object not be removed
> when some other reference still points to it.
>
> Check out the docs concerning del and reference counting
> if this explanation doesn't help you. I hope that in the
> future __del__ will do what you want it to ;-)
>
> --
> i.A. EVM/HEI
> Where did you want to go again?
>
>
--