2005/5/19, Graham Dumpleton <[EMAIL PROTECTED]>: > > 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
I've thought about using some of the work you did on Vampire, but I'm not really convinced we should go that far. One thing I want to ensure is that normal Python modules and published modules are not the same thing. If I were implementing this in Java (I've did something similar back in the heydays of Java), I would use different ClassLoaders. I'm OK with reloading published modules being automagically reloaded, but I'm not for standard Python modules. Published modules are or should be developed with some assumptions in mind, namely that the module can be reloaded at any time, that it can be executed in a multithreaded environment, and so on. Standard python modules are not always built this way, and not all modules can safely be reloaded (at least, we cannot guarantee this). That is were Vampire worries me, in that it seems to do its job too well by being able to reload a huge bunch of modules if one of the core dependencies change. Or is it ? Frankly, I'm not convinced that being able to hot-swap any piece of code is so important. What's the problem with doing an "apachectl restart" ? There is not interruption of service as Apache is gracefully closing one set of worker processes while starting a new set of workers and keeping incoming connections in a buffer until the new worker is ready to go on. This way, you get a pristine environment to work with, and not some kind of weirdo, half correctly reloaded, half "not meant to be reloaded", PLUS half "cannot be properly reloaded in a multi-threaded context" execution environment :). Reloadable published modules is handy during development, but a fully reloadable module set (published + standard modules) is a promise for strange behaviour. As far as we have to dynamically load an arbitrary piece of code for a given file and use it as a module, there was not much to do to add the possibility of reloading a modified module. We could introduce some dependency checks when a published module uses code from another published module. But going further seems a bit dangerous and not really useful to me. That said, I don't want to undermine the feat you accomplished in implementing the Vampire module cache. There a a bunch of neat ideas in your code, and the possibility to keep some data during the reload is very clever. It's just that what is totally justified for the Vampire publisher may not be needed for the simpler mod_python.publisher. Regards, Nicolas
