scoping/module life puzzle

[Robin Becker]

In article <Gr6dnTVwuvzbeHegXTWc3A at comcast.com>, Justin Shaw
<wyojustin at hotmail.com> writes
..
.....Thanks for your attempted explanation. I had thought that holding a
reference to an attribute would inhibit object destruction. I suppose
this must be another of Python's many special cases ie holding a
reference to m.run doesn't prevent the dismantling  of m itself. This
might explain a few problems with window destruction under various
anygui backends.


The second problem is really the same ie nothing keeps A() alive when
run() returns so the ref to m goes and haha.

Is there some special reason why holding a reference to the code object
created in m's __dict__ doesn't keep the module alive? 


Is there a correct way to install code into a module?
 
>t reference the run method.
>
>All of the local variables inside A.run() will vanish when with function
>returns.  This includes the local variable 'm'.  If you want to use it next
>time around you need to save it somewhere besides the local name space (i.e.
>as an attribute of self).  You could just as easliy assign directly to
>self._m if you wished.
>
>> Secondly even if I keep the module referenced why does A().run()(L)
>> crash when a=A();a.run()(L) doesn't?
>
>You are tossing the reference to object that contains run() and join gets
>clobbered.  There are two fixes that you could do.
>1. ' '.join(L) # use the space's join method (recommended)
>2. stash a reference to self in the global name space:
>def run(self):
>    global saveme
>    saveme = self
>    ...
>
>Odds are there is a better way to do what you are attempting.
>
>Justin
>
>

-- 
Robin Becker