Re: Destructor Woes, was Advice needed on __del__
phil wrote: Then i got a tip that you can register a function that needs to be called when the object is going to be deleted. For instance to register a function __exit, you do this: Here is the complete line class with your suggestion: Below is the output. Nice idea, maybe I did something wrong? class line: def __init__(s,glob,argl,color=''): atexit.register(s.__exit) s.glob = glob s.type = 'line' s.color = color if not s.color: s.color = glob.color if len(argl) == 2: wobj = glob.objs[ argl[0] ][0] s.x0 = a0 = wobj.x s.y0 = b0 = wobj.y wobj = glob.objs[ argl[1] ][0] s.x1 = a1 = wobj.x s.y1 = b1 = wobj.y elif len(argl) == 4: s.x0 = a0 = float( argl[0] ) s.y0 = b0 = float( argl[1] ) s.x1 = a1 = float( argl[2] ) s.y1 = b1 = float( argl[3] ) else: return s.midx = (s.x0 + s.x1) / 2 s.midy = (s.y0 + s.y1) / 2 s.len = sqrt( (s.x1 -s.x0)**2 + (s.y1 -s.y0)**2 ) if (s.y1 -s.y0) == 0: s.slope = 0 elif (s.x1 -s.x0) == 0: s.slope = 99 else: s.slope = ( (s.y1 -s.y0) / (s.x1 -s.x0) ) # center point of graph is 400,300 # scale is no of pixels per unit of measure x0 = a0 * s.glob.scale + 400 y0 = 300 - b0 * s.glob.scale x1 = a1 * s.glob.scale + 400 y1 = 300 - b1 * s.glob.scale s.obj = glob.can.create_line(x0,y0,x1,y1, width=glob.width,fill=s.color) def __exit(s): print 'exit' s.glob.can.delete(s.obj) # def __del__(s): # s.glob.can.delete(s.obj) exit Error in sys.exitfunc: Traceback (most recent call last): File /usr/local/lib/python2.3/atexit.py, line 20, in _run_exitfuncs func(*targs, **kargs) File ./graph.py, line 972, in __exit s.glob.can.delete(s.obj) File /usr/local/lib/python2.3/lib-tk/Tkinter.py, line 2085, in delete self.tk.call((self._w, 'delete') + args) _tkinter.TclError: invalid command name .1076354284 I don't know what's wrong in your example. Here it works (doesn't help you of course). I would first try with an easy example an try to test the atexit functionality like that. It seems that the problem you are having isn't related to the atexit part. Sorry i couldn't be of more help Benedict -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructor Woes, was Advice needed on __del__
flupke wrote: Then i got a tip that you can register a function that needs to be called when the object is going to be deleted. For instance to register a function __exit, you do this: class line: def __init__(s,glob,argl,color=''): atexit.register(s.__exit) I don't know what's wrong in your example. Here it works (doesn't help you of course). I would first try with an easy example an try to test the atexit functionality like that. It seems that the problem you are having isn't related to the atexit part. do you (or whoever gave you the tip) have the slightest idea what atexit does? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructor Woes, was Advice needed on __del__
phil [EMAIL PROTECTED] wrote: Then i got a tip that you can register a function that needs to be called when the object is going to be deleted. For instance to register a function __exit, you do this: Here is the complete line class with your suggestion: Below is the output. Nice idea, maybe I did something wrong? class line: def __init__(s,glob,argl,color=''): atexit.register(s.__exit) atexit is used to clean up when the *interpreter* shuts down, not when any object is going to be deleted. File /usr/local/lib/python2.3/lib-tk/Tkinter.py, line 2085, in delete self.tk.call((self._w, 'delete') + args) _tkinter.TclError: invalid command name .1076354284 this usually means that you're trying to execute Tkinter methods on a widget that no longer exists (probably because Tkinter has been shut down, at this point). /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructor Woes, was Advice needed on __del__
do you (or whoever gave you the tip) have the slightest idea what atexit does? Yeah, I got the tip on this group. researched and found it was for when program ends! I was trying to treat it like a destructor. darn. -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructor Woes, was Advice needed on __del__
Fredrik Lundh wrote: flupke wrote: Then i got a tip that you can register a function that needs to be called when the object is going to be deleted. For instance to register a function __exit, you do this: class line: def __init__(s,glob,argl,color=''): atexit.register(s.__exit) I don't know what's wrong in your example. Here it works (doesn't help you of course). I would first try with an easy example an try to test the atexit functionality like that. It seems that the problem you are having isn't related to the atexit part. do you (or whoever gave you the tip) have the slightest idea what atexit does? /F As i said, it works for me. I use it to log the closure of my main program. Maybe my first message wasn't clear on the use of atexit. Benedict -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
phil wrote: If someone doesn't know the answer to this question or if noone knows the answer to this question there is no answer to your question. Python works as specified in the language specification, and the language specification makes no guarantees. changes in the CPython interpreter has affected finalization order before, and may do it again. nobody will break your code on purpose, but if it relies on implementation artefacts, it will break, sooner or later. you haven't answered my question, btw: why are you using __del__ to do something that the garbage collector should do for you? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
On Mon, 09 May 2005 22:49:06 -0300, André Roberge wrote: Scott David Daniels wrote: André Roberge wrote: ... Each time I refresh the screen, I could force that call, then check to see if Evil has been destroyed by Python, which would give me the information I need to destroy Evil_twin behind the scene myself - which is what I am really after. Wouldn't it be better if the robots draw themselfs onto the canvas? That way you don't have to worry about deletion, a robot would only draw itself when he's has to. So perhaps it's an idea to delegate the drawing of stuff to the objects themself rather then in the 'visibleworld' class. However (famous last words follow...) I feel it's not going to bite me this time. The main reason is that, when Evil is gone, before the screen gets updated, lots of drawing calls and wxYield() calls are made, so that __del__ has lots of time to get called. Your relying on something that *will* bite you, the question is rather *when* will it bite you :-) IMHO, the approach to rely on Python to do your dirty work and then checks if it's done seems a bit VB to me :-) Stas Zytkiewicz -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
stasz wrote: On Mon, 09 May 2005 22:49:06 -0300, André Roberge wrote: Scott David Daniels wrote: André Roberge wrote: ... Each time I refresh the screen, I could force that call, then check to see if Evil has been destroyed by Python, which would give me the information I need to destroy Evil_twin behind the scene myself - which is what I am really after. Wouldn't it be better if the robots draw themselfs onto the canvas? That way you don't have to worry about deletion, a robot would only draw itself when he's has to. So perhaps it's an idea to delegate the drawing of stuff to the objects themself rather then in the 'visibleworld' class. I thought about doing something like this... but gave it up. The other way works well. However (famous last words follow...) I feel it's not going to bite me this time. The main reason is that, when Evil is gone, before the screen gets updated, lots of drawing calls and wxYield() calls are made, so that __del__ has lots of time to get called. Your relying on something that *will* bite you, the question is rather *when* will it bite you :-) Well, since 1) this is used only as a demonstration of scoping in Python, in one example 2) other examples do not involve the temporary creation of robots (i.e. they would never go out of scope) 3) it works so far... I'll wait for someone telling me that demonstration doen't work for them. ;-) IMHO, the approach to rely on Python to do your dirty work and then checks if it's done seems a bit VB to me :-) Ouch! You don't mince words, do you? Trying to get the QOTW? ;-) Stas Zytkiewicz Unless I am sorely mistaken, I believe *you* have a full copy of the source code. Why don't you try and see if your approach can be incorporated in the program? I'll buy you a beer if you make it work! ;-) André -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
phil wrote: snip A class instance based language doesn't have to BE C++ to have a destructor method. All I wanted to know is: is the apparent treatment of __del__ which SEEMS to work fine for me in 2.3.4 deprecated or mangled in some later release or future plans. If someone doesn't know the answer to this question or if noone knows the answer to this question, I will still love and respect the Python Community. In large part cause it ain't C++ I like to use destructors to and find the way __del__ works a bit strange. For instance if you want to use a class variable in the __del__ function it's possible that it's not reachable via classname.variable and then you have to call it via self.__class__.variable. I find this non intuitive. I heard the explanations why but that doens't make it more intuitive. Then i got a tip that you can register a function that needs to be called when the object is going to be deleted. For instance to register a function __exit, you do this: import atexit ... class Bla: def __init__(self) ... atexit.register(self.__exit) ... def __exit(self): It still doesn't feel right to me as i would rather use __del__ but since the behaviour can't be predicted, using atext is the next best thing Benedict -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
phil wrote: I'm probably dense and don't quite get the point, even though I have coded about 200,000 lines of Python and coded .5 million lines of C before there was a C++ A class instance based language doesn't have to BE C++ to have a destructor method. Very true. But meaningful finalizers are a difficult problem in languages like Python. For example: class A: def __del__(self): print self.b class B: def __init__(self, a): self.a = a def __del__(self): print self.a a = A() a.b = B(a) del a What should happen? How would you implement that behavior? How would you implement that behavior on Java and .NET (neither of which gaurantee that finalizers/destructors will be called). All I wanted to know is: is the apparent treatment of __del__ which SEEMS to work fine for me in 2.3.4 deprecated or mangled in some later release or future plans. __del__ is not currently gauranteed to do anything. Currently it does something. Depending on that something is a bad idea. Could you explain your problem in more detail - maybe we'll have some suggestions. Cheers, Brian -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
=?ISO-8859-1?Q?Andr=E9_Roberge?= [EMAIL PROTECTED] wrote: If I need to have the user call Evil.destroy() as Evil is getting out of scope, it would miss the whole point of teaching about the natural way scope and namespace work. The problem, it seems to me, is that in Python scope applies to names, but you're trying to apply it to objects. A name going out of scope shouldn't be assumed to have much of an impact on the object it referred to, and by emphasising too close a link between name and object I think you're more likely to run into trouble later on. As was pointed out upthread, Python isn't C++. (Speaking as someone who's been bitten by a very similar issue due to Java not being C++ either.) -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | Frankly I have no feelings towards penguins one way or the other \X/ |-- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
André Roberge wrote: If I need to have the user call Evil.destroy() as Evil is getting out of scope, it would miss the whole point of teaching about the natural way scope and namespace work. well, if you insist on using finalizers to keep track of what's in the current scope, I'd say that you are missing the point about how scopes and name- spaces work... (to track the contents of a scope, you have to look at the scope.) A thought occurred to me, regarding when __del__ is called. Can I force Python, through some function call, to perform this. Each time I refresh the screen, I could force that call, then check to see if Evil has been destroyed by Python, which would give me the information I need to destroy Evil_twin behind the scene myself - which is what I am really after. the correct solution is to inspect the current namespace every time you refresh the screen, and make sure the screen contents matches what's in the namespace. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
Fredrik Lundh wrote: André Roberge wrote: If I need to have the user call Evil.destroy() as Evil is getting out of scope, it would miss the whole point of teaching about the natural way scope and namespace work. well, if you insist on using finalizers to keep track of what's in the current scope, I'd say that you are missing the point about how scopes and name- spaces work... I don't think I do, but I think I didn't explain things well enough. 1. The user creates an object, within a local scope. When he does that, I update a list of images in a global scope. I then use that list of images to decide what to display on the screen. The user is unaware of the connection I am making behind the scene. [Snip] the correct solution is to inspect the current namespace every time you refresh the screen, and make sure the screen contents matches what's in the namespace. To do that, I would need to put a link, in the global scope between the object created by the user, and the user. However, in doing so (if I am not missing the point about how scopes and namespaces work...) the object created by the user would always have a reference in the global scope ... and thus would never disappear from the namespace. I understand that, if the link is a weak reference, then it might disappear when the object goes out of scope. Is that what you mean I should do? André /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
André Roberge wrote: Scott David Daniels wrote: André Roberge wrote: ... Each time I refresh the screen, I could force that call, then check to see if Evil has been destroyed by Python, which would give me the information I need to destroy Evil_twin behind the scene myself - which is what I am really after. What might work is to keep a weakref to Evil in Evil_twin. Upon refresh, you could check if the weakref has gone stale. Is that good enough? ... Try something like this: ++ import weakref class UsedRobot(object): -- def __init__(self, ..., parent=Visible_world()): ++ def __init__(self, ..., jeckyll=None, parent=Visible_world()): ++ # need to know if we are good or evil. # Visible_world is a Singleton - see Python cookbook --true_robot = parent.addOneRobot(...)# ---Evil_twin created self.robot = parent.robot_dict[true_robot.name] self.name = true_robot.name self.program = rur_program() # Singleton self.parent = parent self.parent.object_dict[self.name] = True # --- new trick self.program.wait_update_refresh(self.robot, self.name) ++ if jeckyll is None: ++ # Making a good twin. Make an evil partner ++ twin = parent.addOneRobot(..., jeckyll=self) ++ self.twin = lambda: return twin # match weakref interface ++ # hold a ref to the evil twin, so it will be alive ++ else: ++ # Making an evil twin. Make a weak ref to the good ++ twin = parent.addOneRobot(..., jeckyll=self, ...) ++ self.twin = weakref.ref(jeckyll) --def __del__(self): --self.parent.object_dict[self.name] = False ... Somewhere else when deciding to draw a particular robot: ... robot = whatever ... -- draw robot ++ if robot.twin() is None: ++ # This must be an evil twin with a dead good twin ++ avoid drawing robot ++ else: ++ # this is either a good twin or ++ draw robot ... --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Destructor Woes, was Advice needed on __del__
Then i got a tip that you can register a function that needs to be called when the object is going to be deleted. For instance to register a function __exit, you do this: Here is the complete line class with your suggestion: Below is the output. Nice idea, maybe I did something wrong? class line: def __init__(s,glob,argl,color=''): atexit.register(s.__exit) s.glob = glob s.type = 'line' s.color = color if not s.color: s.color = glob.color if len(argl) == 2: wobj = glob.objs[ argl[0] ][0] s.x0 = a0 = wobj.x s.y0 = b0 = wobj.y wobj = glob.objs[ argl[1] ][0] s.x1 = a1 = wobj.x s.y1 = b1 = wobj.y elif len(argl) == 4: s.x0 = a0 = float( argl[0] ) s.y0 = b0 = float( argl[1] ) s.x1 = a1 = float( argl[2] ) s.y1 = b1 = float( argl[3] ) else: return s.midx = (s.x0 + s.x1) / 2 s.midy = (s.y0 + s.y1) / 2 s.len = sqrt( (s.x1 -s.x0)**2 + (s.y1 -s.y0)**2 ) if (s.y1 -s.y0) == 0: s.slope = 0 elif (s.x1 -s.x0) == 0: s.slope = 99 else: s.slope = ( (s.y1 -s.y0) / (s.x1 -s.x0) ) # center point of graph is 400,300 # scale is no of pixels per unit of measure x0 = a0 * s.glob.scale + 400 y0 = 300 - b0 * s.glob.scale x1 = a1 * s.glob.scale + 400 y1 = 300 - b1 * s.glob.scale s.obj = glob.can.create_line(x0,y0,x1,y1, width=glob.width,fill=s.color) def __exit(s): print 'exit' s.glob.can.delete(s.obj) # def __del__(s): # s.glob.can.delete(s.obj) exit Error in sys.exitfunc: Traceback (most recent call last): File /usr/local/lib/python2.3/atexit.py, line 20, in _run_exitfuncs func(*targs, **kargs) File ./graph.py, line 972, in __exit s.glob.can.delete(s.obj) File /usr/local/lib/python2.3/lib-tk/Tkinter.py, line 2085, in delete self.tk.call((self._w, 'delete') + args) _tkinter.TclError: invalid command name .1076354284 -- http://mail.python.org/mailman/listinfo/python-list
Advice needed on __del__
Suppose I have two classes: 'Jekyll' and 'Hyde' that are related in a particular way. When I create a Jekyll object, a Hyde one gets automatically created (and displayed on a screen). drum roll to announce Python script === Nice = Jekyll()# Nice_twin, a Hyde object, gets created. Nice.doStuff() # Nice_twin is doing his own stuff def subplot(): Evil = Jekyll() # Evil_twin gets created and displayed Evil.doStuff()# Evil_twin does stuff on the screen subplot() #Evil.doMoreStuff() would raise an error, as it no longer exists # in this namespace; however, Evil_twin still displayed Nice.doMoreStuff() # continues to work. ==End of script, and ask question=== Evil_twin is still displayed on the screen at the end. I would like for Evil_twin to disappear. (I would like for this Hyde, to hide ok, bad pun!) This morning I had the following thought: I can, when I create a Jekyll object, update an outside_list. If, somehow, I could update that list when a Jekyll object disappears (perhaps by using __del__, which I have never touched) that would solve my problem. I could check outside_list each time I update the screen display, and remove Evil_twin when Evil no longer exists. Any suggestions? I've already tried lots of things, but nothing works properly. Every attempt I make involves quite a bit of coding, as the real-life situation is a bit more complicated than what I explain here. So, before I try again, I thought I would ask the Collective Wisdom on this list. -- André -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
André Roberge wrote: This morning I had the following thought: I can, when I create a Jekyll object, update an outside_list. If, somehow, I could update that list when a Jekyll object disappears (perhaps by using __del__, which I have never touched) Python makes no guarantees whatsover about when and how to run __del__, so relying on it to remove user-visible resources is a rather bad idea. Any suggestions? why wouldn't def subplot(): Evil = Jekyll() # Evil_twin gets created and displayed Evil.doStuff()# Evil_twin does stuff on the screen Evil.destroy() work for you? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
phil wrote: Python makes no guarantees whatsover about when and how to run __del__, so relying on it to remove user-visible resources is a rather bad idea. What does that mean? Is it a destructor or not? it's a finalizer. most Python implementations do a reasonable attempt to call finalizers on all objects, sooner or later, but it's not guaranteed by the language specification: It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. I create thousands of instances of objects in a geometry instruction program and rely heavliy on __del__ to do its thing. For instance when I am rotating objects, I delete and recreate somtimes hundreds of times. Works so far. why do you rely on __del__ to remove your objects? why not just leave that to the garbage collector? (__del__ disables cycle detection, so a program that uses __del__ carelessly is more likely to leak memory than a program that doesn't use it at all). 2. If Python is an oop language, meaning instances of classes are essential, then a reliable destructor method is essential. Python is not C++. /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
Fredrik Lundh wrote: André Roberge wrote: This morning I had the following thought: I can, when I create a Jekyll object, update an outside_list. If, somehow, I could update that list when a Jekyll object disappears (perhaps by using __del__, which I have never touched) Python makes no guarantees whatsover about when and how to run __del__, so relying on it to remove user-visible resources is a rather bad idea [See idea at the very end about this.] Any suggestions? why wouldn't def subplot(): Evil = Jekyll() # Evil_twin gets created and displayed Evil.doStuff()# Evil_twin does stuff on the screen Evil.destroy() work for you? /F Unfortunately, it wouldn't. It's difficult to explain in a few words why, but I'll try anyway! I'm developping a program (rur-ple) which is designed to help learning Python. In an earlier version (that didn't provide support for deriving classes from existing one) I had it working so that when Evil would get out of scope, Evil_twin would disappear from the screen. This came as an initial surprise for me, but a pleasant one. Better than having an example like: def boring(): x = 1 print x boring() print x # gives an error message. When I added the possibility of deriving classes, I had to change the connection between Jekyll and Hyde ... and, so far, lost that feature. If I need to have the user call Evil.destroy() as Evil is getting out of scope, it would miss the whole point of teaching about the natural way scope and namespace work. I guess I'll have to try and learn how to use __del__, and see if it can solve my problem. === A thought occurred to me, regarding when __del__ is called. Can I force Python, through some function call, to perform this. Each time I refresh the screen, I could force that call, then check to see if Evil has been destroyed by Python, which would give me the information I need to destroy Evil_twin behind the scene myself - which is what I am really after. -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
André Roberge wrote: ... Each time I refresh the screen, I could force that call, then check to see if Evil has been destroyed by Python, which would give me the information I need to destroy Evil_twin behind the scene myself - which is what I am really after. What might work is to keep a weakref to Evil in Evil_twin. Upon refresh, you could check if the weakref has gone stale. Is that good enough? --Scott David Daniels [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
Hi All-- Fredrik Lundh wrote: Python is not C++. I dunno if this makes QOTW, but I vote we put this in our list text that goes out with each and every list message. There will still be a lot of people who don't read it, but at least we'll get to say, We told you so. do-buddhists-get-to-say-that?-ly y'rs, Ivan;-) -- Ivan Van Laningham God N Locomotive Works http://www.pauahtun.org/ http://www.foretec.com/python/workshops/1998-11/proceedings.html Army Signal Corps: Cu Chi, Class of '70 Author: Teach Yourself Python in 24 Hours -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
phil [EMAIL PROTECTED] writes: By the way, I understand that __del__ is only called when the last reference to an instance is deled. That's fine, if consistent. Actually, __del__ is called when the instance is garbage collected. Exactly when that is is implementation dependent. In the implementation you happen to be using, it'll happen when the last reference is deleted. But depending on this makes your code less portable. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
Fredrik Lundh wrote: Python is not C++. Praise the Lord. I dunno if this makes QOTW, but I vote we put this in our list text that goes out with each and every list message. There will still be a lot of people who don't read it, but at least we'll get to say, We told you so. I'm probably dense and don't quite get the point, even though I have coded about 200,000 lines of Python and coded .5 million lines of C before there was a C++ A class instance based language doesn't have to BE C++ to have a destructor method. All I wanted to know is: is the apparent treatment of __del__ which SEEMS to work fine for me in 2.3.4 deprecated or mangled in some later release or future plans. If someone doesn't know the answer to this question or if noone knows the answer to this question, I will still love and respect the Python Community. In large part cause it ain't C++ -- http://mail.python.org/mailman/listinfo/python-list
Re: Advice needed on __del__
Scott David Daniels wrote: André Roberge wrote: ... Each time I refresh the screen, I could force that call, then check to see if Evil has been destroyed by Python, which would give me the information I need to destroy Evil_twin behind the scene myself - which is what I am really after. What might work is to keep a weakref to Evil in Evil_twin. Upon refresh, you could check if the weakref has gone stale. Is that good enough? It might be I guess ... but I don't know how to keep a weakref. (Whips out Python in a Nutshell... yes, it's there :-) Hmmm... The way my program is structured, Evil_twin gets created immediately *after* Evil is created. If it were the reverse, I think I could do it, but I am really not sure in this case. However, I did try it with __del__ as I described, and, after a bit of fiddling got it to work perfectly. I understand about the possible platform dependence issue. However (famous last words follow...) I feel it's not going to bite me this time. The main reason is that, when Evil is gone, before the screen gets updated, lots of drawing calls and wxYield() calls are made, so that __del__ has lots of time to get called. === For the curious, here's how I do it: (Sorry, no Jekyll and Hyde here :-( class UsedRobot(object): def __init__(self, ..., parent=Visible_world()): # Visible_world is a Singleton - see Python cookbook true_robot = parent.addOneRobot(...)# ---Evil_twin created self.robot = parent.robot_dict[true_robot.name] self.name = true_robot.name self.program = rur_program() # Singleton self.parent = parent self.parent.object_dict[self.name] = True # --- new trick self.program.wait_update_refresh(self.robot, self.name) def __del__(self): self.parent.object_dict[self.name] = False class Visible_world() stuff below: # lots os stuff omitted def DoDrawing(self): # start doing lots of background stuff # enough time to call __del__ ? self.world_image = wxEmptyBitmap(self.maxWidth, self.maxHeight) dc = wxMemoryDC() dc.SelectObject(self.world_image) dc.Clear() dc.BeginDrawing() self.DrawBackground(dc) self.DrawWalls(dc) self.DrawBeepers(dc) # ok, were we go with the important stuff for this post list_to_ignore = [] for item in self.object_dict: # see new trick above if not self.object_dict[item]: list_to_ignore.append(item) for name in self.robot_dict: if name not in list_to_ignore: self.DrawRobot(dc, name) dc.EndDrawing() self.updateImage = True -- http://mail.python.org/mailman/listinfo/python-list
