On 19/05/2005, at 7:24 PM, Nicolas Lehuen wrote:
The handle around the module worries me a bit as it would appear to
work in read mode only. Ie., not sure it would work if someone tried to
actually set a global variable within the module from outside of it.
The lack of __setattr__() means it will probably set the variable in the
handle and not the cached module.
Yeah, I've thought about that, but setting an attribute to a module which can be reloaded at any time does not seem a good idea to me. I think the get_page() function (which return a module instance valid for the duration of the request) is much more robust, since it reckons that a published module is a volatile object.
There is another way which would not rely on wrapper objects : it is simply to add the imported file to the dependencies of the importing file, so that whenever the imported file changes, its page is rebuilt and the importing page is also rebuilt. This is not really difficult to do and could be cleaner and faster.
You should really look at the module caching mechanism in Vampire sometime,
it effectively does what you are now talking about. Vampire takes this to
the point of doing a depth search for dependencies and reloading a top
level module if any of the nested dependencies, even a few levels below,
have changed. Am sure that some will criticise this as being inefficient
but I design for usability over break neck speed. Anyway, based on number
of downloads Vampire isn't being used much by anyone but me, so still very
much my toy for trying out ideas.
The cache code can be seen at:
http://svn.dscpl.com.au/vampire/trunk/software/vampire/cache.py
If you are interested in peering into some of the cache information for my
own web site, check out:
http://www.dscpl.com.au/projects/vampire/examples/templates/ cached_modules.html
Graham
