list at joreybump.com
Thu Jul 1 18:29:27 EDT 2004
Nicolas Lehuen wrote: > Jorey Bump wrote: > >>Modules are namespaces, regardless of their physical >>location. This is very important, even within subinterpreters. > > I do understand this, and that's why I think that the module defined in > /app/index.py should not be overwritten by the one defined in > /app/subdir/index.py. Maybe the namespace of the module defined by > /app/subdir/index.py should be created within the namespace of the module > defined by /app/index.py, so that the latter would inherit names from the > former ? It seems that the publisher load each .py file as modules based on > the filename only, hence the name collisions. If directories or URIs could > be taken into account, this collision problem would disappear. Modules of the same name cause collisions. It's that simple. To avoid collisions, create packages and name them carefully. It's like indentation: It imposes a discipline that has enormous benefits that aren't immediately apparent. The file hierarchy is important to the mechanics of creating your environment (setting the PYTHONPATH, creating packages, etc.), but plays no part in the logic of your application. Just as you can't give two files in the same directory the same name, you can't give two modules in the top level of your application the same name. If you want to reuse a name, you have to distinguish it by placing it within a package. There's no need to force mod_python to do this, when you can indicate this yourself by placing __init__.py in the directory you want to package. Automagic packaging could break a lot more than it fixes (you'd have to memorize every module or package in your path before creating directories). >>mod_python already puts the directory at the front of the >>sys.path. You can determine this by creating a module: > > [snip code] > > Well, that's the first thing I tried a few month ago, but that's not the > case on my installation (Apache2 + mod_python running on Windows 2000 SP4). I'm currently developing on Debian Gnu/Linux, and it's likely that there are important configuration differences in my environment. > Maybe this is due to the fact that I used the PythonPath directive ? I > defined it like this (in httpd.conf) : > > LoadModule python_module python/mod_python.so > AddHandler mod_python .py .psp > PythonPath > "sys.path+['C:/apache/python/Lib','C:/apache/Subversion/python','C:/apache/t > rac']" > PythonHandler mod_python.publisher | .py > PythonHandler mod_python.psp | .psp > PythonDebug On I use this, and nothing else (apache 1.3.26, mod_python 2.7.8): <Directory /var/www/site> AddHandler python-program .py PythonHandler mod_python.publisher PythonDebug On </Directory> Obviously, this is an older, patched version and there will be differences. The main point is that it might be better to start with a simple configuration and find a Python-based solution, rather than trying to bend mod_python to your will. > How can I benefit from the behaviour you describe while also declaring the > libraries I need on the Python path ? This depends on your environment and your privileges. First, try the test I outlined to verify your path under Apache/mod_python (remove your PythonPath directive for the test). One solution is to create packages in your existing path. Anything you put in your installation's site-packages directory will be available to everyone on the system. In fact, that's why it was created. If you don't like or have that option, see if the default path suggests a place for your packages. If not, you may want to specify a single location for convenience and security, and preface your path with it. The benefits of this are clearly dependent on your target environment. Wherever you end up putting your packages and modules, remember that, unlike HTML, they don't need to be in your DocumentRoot, just your PYTHONPATH. This means that you can create a single interface for each application: /var/www/app/app1.py /var/www/app/app2.py ... This encourages you to create generic packages that can be easily shared by all of your applications. Don't worry about index.py, unless you want to control *all* of your applications from that single file (just add a new function to launch each app). An index.html will serve the purpose just as well. It's great to have power and exercise it, but it's even nicer to be waited on hand and foot. Let Python do some of the work for you.