scoping/module life puzzle

[Robin Becker]

In article <asgluh$d49$0 at 216.39.172.122>, Bengt Richter <bokr at oz.net>
writes
>On Fri, 29 Nov 2002 11:23:31 +0000, Robin Becker <robin at jessikat.fsnet.co.uk> 
>wrote:
>
>>I would be grateful if someone can explain what's going on here. First
>>off why do I need to keep a reference to the module (self._m=m) If I
>>don't then it seems as though the module is dismembered (join-->None)
>>even though the module object has an extant reference the run method.
>>
>>Secondly even if I keep the module referenced why does A().run()(L)
>>crash when a=A();a.run()(L) doesn't?
>>
>Interesting question. On the face of it, it looks like a bug. I.e., as though
>a temp object is being created without incrementing and then decrementing a ref
>count for something it's using, maybe mistakenly assuming a reference somewhere
>can just be borrowed?
>
>But the other question is, why do you need a module? If you just want
>dynamically to create and cache a function called run, why not just do it? 
>E.g.,
>
.....I'm probably being stupid. Historically we started with files
imported on the fly, that causes problems when the module names are the
same so I switched to creating the modules on the fly. Of course If I
keep the code cached things seem OK so perhaps you're right I need only
read the file and get the cached code thing. In our application the
function names are likely to be constant across many documents they're
called beforePage & afterPage so a single cache won't work. I guess I
need a dict of dicts to do what you suggest. So for a doc called 'x.pdf'
I look for a decorator in 'x.py' and store the result in
cache[digest('x.pdf')]['run']
-- 
Robin Becker