5.1.1 Python*Handler Directive Syntax
All request handler directives have the following syntax:
Python*Handler handler [handler ...] [ | .ext [.ext ...] ]
Where handler is a callable object that accepts a single
argument - request object, and .ext is a file extension.
Multiple handlers can be specified on a single line, in which case
they will be called sequentially, from left to right. Same handler
directives can be specified multiple times as well, with the same
result - all handlers listed will be executed sequentially, from first
to last. If any handler in the sequence returns a value other than
apache.OK , then execution of all subsequent handlers is aborted.
The list of handlers can optionally be followed by a | followed
by one or more file extensions. This would restrict the execution of
the handler to those file extensions only. This feature only works for
handlers executed after the trans phase.
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.
Object can also contain dots, in which case it will be resolved from
left to right. During resolution, if mod_python encounters an object
of type <class> , it will try instantiating it passing it a single
argument, a request object.
If no object is specified, then it will default to the directive of
the handler, all lower case, with the word "python"removed. E.g. the default object for PythonAuthenHandler would be
authenhandler.
Example:
PythonAuthzHandler mypackage.mymodule::checkallowed
For more information on handlers, see Overview of a Handler.
Side note: 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.
|