On 19/05/2005, at 11:16 PM, Nicolas Lehuen wrote:
OTOH, you have implemented a clever import hook that allows users to keep on using the familiar import statement, but I don't feel very comfortable with this idea. I like the import statement semantics to remain always the same, and the way import hooks are managed globally makes me feel a bit nervous. For example, are you sure you don't get some stale import hooks in the import hooks chain whenever the Vampire handler is reloaded ?
Unfortunately the import hook mechanism isn't ideal. The biggest problem is that there can only really be one application wide import hook, at least perhaps if you want to support older versions of Python, don't know about newer versions of Python. This means that if some other module got loaded before Vampire which overrode the import hook, Vampire wouldn't install its own and the feature wouldn't work.
I still need to do more investigation work on the import hook to see if it is at all possible to override it just for specific modules, ie., those loaded using the custom module loader. If I can find a way of doing this, then great. If not, am always at the risk that if mod_python were to do a similar thing that my way of doing it would stop working, although, just had an idea how it could be done in mod_python and I could still make use of it. :-)
The only reason the import hook exists at all is so that Cheetah templates
can be used and for the dependency checks of the module loader to work.
The issue here is that the cheetah-compile program when you extend a
page definition in another file, generates code of the form:
from base_class import base_class
There is no way in the code generator to change this behaviour, without modifying the Cheetah source code, so that I could instead substitute an explicit call to the module loader instead.
Thus it has a quite specific use at the moment and because of the danger
of it messing with normal imports will only work in quite constrained
circumstances. Specifically, you have to turn it on first with the
VampireImportHooks option. This will then only work for modules which
have been loaded by the module loader in the first place and it will only
look in the same directory as the file the import is being done in.
Ie., it will not arbitrarily search sys.path. If you do want it to search
other directories as well, you have to go to extra effort to define the
path in the Vampire configuration file. This path though shouldn't overlap
sys.path and PythonPath would want to be set to "sys.path" so no part of
the document tree ever gets added to "sys.path".
In other words, a conscious decision needs to be made for it to come
into play at all and it would only be recommended for where you can't
avoid using it. With your frame peek code that I have also now integrated,
one can do a module import from the same directory with one line anyway,
so the argument that using "import" is simpler, is less of one and thus
the import hook would really only be for special cases.
Anyway, now, I don't know what to do :). Should I add this dependency management to the existing code or integrate some code from Vampire ?
I certainly at this stage wouldn't be rushing to do in mod_python what I have been doing. Even if it were added at some later date, I would probably require it to be enabled explicitly through an option, using the current simple and more efficient mechanism as the default.
I think at the moment there are going to be enough issues with the loader
you have introduced with publisher for people to worry about as it is.
Am a bit worried that the way that certain aspects of the loader don't
behave the same as before might be an issue for some code. It may be
necessary to consider options that can be enabled to make it behave a
bit more like it used to, although this introduces the same sorts of
problems as auto reload being set to different values in different parts
of a document tree.
Anyway, when I get a chance I'll read through your code again and see if my concerns are valid or not and post something about it. From that you may see why I had to add certain features in my own module loader.
Graham
