|
Jorey Bump
list at joreybump.com
Mon Jan 24 14:32:05 EST 2005
Nicolas Lehuen wrote: > On Mon, 24 Jan 2005 16:28:47 +0100, Nicolas Lehuen > <nicolas.lehuen at gmail.com> wrote: > >>On Mon, 24 Jan 2005 09:12:24 -0500, Jorey Bump <list at joreybump.com> wrote: >> >>>Nicolas Lehuen wrote: >>The problem is that mod_python.publisher does not follow the standard >>Python way in that it imports published modules as root-level modules. Yes, it's true that it strips away leading path information to put all modules on an even plane. I find this an easy adjustment to make. Imports done by published modules obey sys.path, so I don't see any problem. >>It's as if mod_python.publisher changed sys.path for each and every >>published module. This is not the standard Python way, and the source >>for many errors. The main effect is that the DocumentRoot might get prepended to sys.path instead of the directory containing the published module. But a single interpreter must have a single working directory, so I consider this an elegant solution. If you modify the path with the PythonPath directive, this will no longer be the case. The DocumentRoot is not prepended to the path and you will be limited to the directories explicitly listed in PythonPath. This can lead to surprising behaviour if you created some modules and packages in the DocumentRoot, because they will no longer work properly. To me, this seems very much like a feature, and not a bug, because it allows you to finetune your environment and offers some nice security capabilities. You are right that it's not expected, but it's not necessarily inconsistent, once you get used to it. Fortunately, I tend to create packages that are available for my apps and put them in predictable locations in the module search path, so I'm not bit by this. You are right that this can be a serious problem for anyone expecting sys.path to be identical to python run from the command line, but it's really a mod_python configuration issue. >>Note that the current package system in Python is way, way smarter >>than mod_python.publisher : in a package, you can import fellow >>modules by giving their local names. It's not recommended by >>pychecker, but it works. The smart part is that if I have this : >> >>/ >> package1.py >>/subdir >> __init__.py >> package1.py >> package2.py >> >>Then whatever I do, /subdir/package1.py is imported as subdir.package1 >>and does not collide with /package1.py. mod_python.publisher is not as >>smart, this is very confusing and surprising, nearly everybody >>complains about this and hence, I think this should be filed as a bug. To be accurate, Python does not import fellow modules or packages -- it prepends the directory containing the main module to sys.path and limits imports to sys.path. As seen above, mod_python also obeys sys.path, so be sure your imported modules/packages are there. >>So maybe apache.import_module should not be modified (except for >>performance, but that's another issue which is already in the bugs >>database), but mod_python.publisher sure has to be changed. Its behaviour is consistent, once you understand it, so I don't see a need for the change. > Or it could be the sign that mod_python.publisher should be completely > erased from the project, since it poses much more problems than it > solves. Maybe we should include both mpservlets and Vampire in > mod_python, and forget about the default publisher (except maybe for > compatibility issues). Yikes! Publisher is simply the best web application framework I have ever used. I've never felt a need to move beyond it, and I'm not menaced by the issues that seem to bother others. I'd rather see it more heavily promoted and the intricacies explained in some more detail. Once you comprehend a few simple rules, it's incredibly powerful and productive. Grisha created a thing of beauty in Publisher, but its simplicity is lost on many people. To remove it would be madness...
|