Graham Dumpleton
grahamd at dscpl.com.au
Sun Dec 31 17:54:07 EST 2006
I am surprised then that what you had before even worked, as it should have been: PythonFixupHandler fixuphandler or: PythonFixupHandler fixuphandler::fixuphandler Using a '.' in the value to the directive, ie., PythonFixupHandler fixuphandler.fixuphandler is not valid as far as being a way to specify the name of the handler function within a module and should have resulted in an attempt to import a submodule called 'fixuphandler' from a package called 'fixuphandler'. If it did work before then you have hit some quirk in old versions of mod_python related somehow to how Python does imports internally. Quoting the mod_python documentation: A handler has the following syntax: module[::object] Where module can be a full module name (package dot notation is accepted), and the optional object is the name of an object inside the module. The "::" was chosen for performance reasons. In order for Python to use objects inside modules, the modules first need to be imported. Having the separator as simply a ".", would considerably complicate process of sequentially evaluating every word to determine whether it is a package, module, class etc. Using the (admittedly un- Python-like) "::" takes the time consuming work of figuring out where the module part ends and the object inside of it begins away from mod_python resulting in a modest performance gain. So, the documentation only really guarantees that '::' will work to distinguish function name from module. Whether '.' is going to work in all situations is debatable and probably somewhat unspecified. So, change the PythonFixupHandler directive to documented way of doing it. As to file structure. Where files are is okay, but still recommend the file names have leading underscores so that mod_python.publisher will ignore them and not expose their contents to access given that you are using mod_python.publisher for the response handler phase. Graham On 31/12/2006, at 9:07 PM, m.banaouas wrote: > > here is my directory organisation: > D:\mydir\ > D:\mydir\fixuphandler.py > D:\mydir\api.py > there is no __init__.py at all. > however, I can make it change to match well practices ... > > Graham Dumpleton a écrit : >> Read description of import_module() in: >> >> http://www.modpython.org/live/mod_python-3.3.0b/doc-html/pyapi- >> apmeth.html >> >> How 3.3.0b treats Python packages is a bit different. >> >> Your error and configuration suggests that what you had previously >> was: >> >> ./fixuphandler/ # directory >> __init__.py # package init file. >> fixuphandler.py # handler file in directory >> fixuphandler() # handler function in file >> >> A little messy, but the important thing is that it only worked >> before because you >> had fixuphandler directory organised as a Python package with an >> __init__.py >> file and mod_python had automatically add the parent handler >> directory into >> sys.path. In 3.3.0b, it doesn't add the parent handler directory >> into sys.path as >> that causes various problems. The new importer instead works out >> where to >> import things from in a different way. On consequence of this >> though is that >> stuff organised as Python packages in a parent handler directory >> will not be >> found. >> >> You have a few options. >> >> 1. Move 'fixuphandler' directory outside of document root and >> using PythonPath >> to say where the parent directory of that directory now is. >> >> 2. If 'fixuphandler/__init__.py' is empty, then delete that file >> and change >> configuration to: >> >> PythonFixupHandler fixuphandler/fixuphandler >> >> 3. Remove 'fixuphandler/__init__.py' again, but use explicit >> reference to handler >> file: >> >> PythonFixupHandler ~/fixuphandler/fixuphandler.py >> >> If you had stuff in 'fixuphandler/__init__.py' and you expect it >> to be executed, then >> you can only do 1 as is. You might want to reconsider >> restructuring your files >> though anyway. >> >> BTW, if you do not have a 'fixuphandler/.htaccess' which has: >> >> deny from all >> >> then easy for a user to access stuff in 'fixuphandler' directory >> that they shouldn't. >> Ie. they could use URL of: >> >> fixuphandler/fixuphandler.py/fixuphandler >> >> and mod_python.publisher will call the fixuphandler a second time. >> If it was >> doing session stuff, that would cause a deadlock. >> >> If the only thing in 'fixuphandler' directory is >> 'fixuphandler.py', you would perhaps >> be better off moving 'fixuphandler.py' to the parent directory and >> call it '_handlers.py'. >> Because it now has a leading underscore, mod_python.publisher >> should ignore >> it and not allow it to be accessed. The configuration would then be: >> >> PythonFixupHandler _handlers >> >> or: >> >> PythonFixupHandler ~/_handlers.py >> >> Anyway, read through the documentation I reference, noting that >> import_module() >> is what is used to load modules for the Python*Handler directives. >> >> Graham >> > > > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python
|