On 19/05/2005, at 8:32 PM, Nicolas Lehuen wrote:
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).
The Vampire module loading mechanism doesn't go anywhere near standard
Python modules. Anything it does load does not get put in sys.modules and
if the advice is taken of setting PythonPath to 'sys.path' there is no
real chance of importing a module using the Vampire import mechanism
at the same time as it is loaded using "import" unless you specifically
go out to break things in that way. Thus, it also is only intended to
be used with published modules or modules which are specifically are
a part of the web application and not some generic module usable outside
of the application.
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" ?
One of the environments I have to work in I have no ability to perform restarts as the system is managed by others. Thus I don't have that luxury. Many users of ISP environments may not have that luxury either.
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 :).
In Vampire, unlike in mod_python's import_module() function, when it does a reload it does not reload on top of an existing module because that I agree is quite dangerous and can result in lots of problems. There are special hooks that can be defined in a module which allow you to migrate data from an existing module to the one being reloaded in a thread safe manner.
The fact that it can look down multiple levels ensures that everything
is consistent as much as possible. This to my mind is much better than
the import_module() method and how it is applied to top level handlers,
where whether auto reload applies depends on what part of the URL
namespace you are in because of the PythonAutoReload option. If different
parts of the URL namespace have different settings for this option they
will screw each other up. Gets worse when using import_module() direct
as auto reload is on or off on a case by case basis because you have
to pass the option in to specify what happens. If an auto reload option
is provided, it needs to turn it off completely for the whole interpreter
for the remaining life of the interpreter. The ability to turn it on and
off at will and at different places at the same time is much worse.
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.
All I can really say is that I have obviously been too clever in as much as it isn't obvious to what extent I have gone to avoid all these problems. :-(
Graham
