[mod_python] fixuphandler problem with mod_python-3.3.0b

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


   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:


   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- 
   "::" takes the time consuming work of figuring out where the  
module part
   ends and the object inside of it begins away from mod_python  
   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

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.


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

More information about the Mod_python mailing list