[mod_python] PythonOption access

Graham Dumpleton grahamd at dscpl.com.au
Fri Jan 21 05:10:54 EST 2005

On 21/01/2005, at 6:05 PM, Bo Lorentsen wrote:

> Graham Dumpleton wrote:
> I am not aware of what the "Vampire" module are, one of Your projects ?

Project site is:


>> If the import function took an optional "req" object, I could place 
>> this
>> into the empty module prior to running execfile() and then remove
>> it afterwards. Ie.,
>>        module = imp.new_module(label)
>>        module.__file__ = file
>>        module.__req__ = req
>>        execfile(file,module.__dict__)
>>        del module.__dict__["__req__"]
> So this is performed in the "python module loader", i guess ?

Yes, but as explained, we aren't using "import" here or even the "imp" 
Would make more sense if you got down Vampire and had a dig around in it
as to how it handles module importing.

> I am using the PythonHandler directly myself, and I guess this is more 
> "low level", so control at this level are not possible ?

This level of control is possible. This wasn't theoretical and is 
practical thing that can be done in Vampire.

>> That way the "req" object could be available just for the period of 
>> the
>> initialisation phase of an import. You probably wouldn't want to
>> cache the req object as it applies to a specific request as the cached
>> module would outlive it. You also wouldn't want to be relying on
>> information specific to a request. You could access the PythonOption
>> values, although you may want to avoid values set in .htaccess files
>> and go for ones you know are set in the httpd.conf file.
> Hmm, I know what You mean, but on the other hand ... I don't use one 
> python script for more than one URL, and if I am, the script still 
> remains in the same physical path in relation to the web server, 
> anyway. Or are we talking about two different things ?

If one using the module import system for sub imports in a content 
then one can theoretically have common modules which are imported based 
different URL request. When doing a sub import though, one might not 
pass through the req to sub imports.

Anyway, one Python file per URL is good, or one Python file per 
resource. This
is actually exactly what Vampire promotes and makes easy to achieve.

>> Anyway, in the end, this would allow you to do something like the
>> following in a content handler.
>>  from mod_python import apache
>>  if __req__ != None:
>>    options = __req__.get_options()
>>    if options.has_key("debug") and options["debug"]:
>>      apache.log_error(...)
> Only ... I dislike the "if" :-)
> I hoped for something like :
>   from mod_python import apache
>   pram = apache.get_option( 'custom_param' )
>   ...
> This is without the "if" as the only problem left will be that 
> "custom_param" don't exist. I think the "__req__" object is a bad 
> idea, as this is not a request situation, but module initialization. 
> We know where the script is (and the .htaccess file), but no request 
> have been send (well it has, but we need not to know about this in the 
> "global" context !).
> Anyway, this is how I dream about it :-)

The "if" on __req__ can be avoided when it is a content handler being 
by the top level PythonHandler dispatcher as it would guarantee it is 
In mod_python 3.1.X, get() can take a default parameter if not set, so 
just have:

   param = __req__.get_options().get("custom_param","0")

>> Overall I am not sure that this is a good idea or not. It has both 
>> good
>> points and bad points.
> I think I know what you mean. It is a "nice to have" thing and I 
> already have a work around for this. But in my search for perfection 
> :-)

This whole idea actually fits in quite well with stuff I
have done with Vampire with configuration files outside of .htaccess 
and automatic search mechanisms to find inherited config. It has always 
a shortcoming that one could only do the config search from inside 
of request handler as one need the req object. With the scheme talked 
here, I can extend ability to access the config during module import 

Anyway, I can hope you find Vampire closer to perfection. :-)

>> Maybe it shouldn't use an actual req object, but a new object which
>> incorporates some of what req provides, dropping stuff that may be
>> more specific to a particular request.
> Thats my point :-)

Possibly not complete, but the things from req it would/could have are:


This means there is nothing which could be used to write data back to 
the remote

Figured I could call it __info__ and not __req__ when populated into the
namespace of the module when loading.

>> Thus you might provide some
>> information about the server and python options, although not sure
>> how you deal with the issue of .htaccess level options being different
>> based on URL used for original request.
> Well there is tho kinds of URL's there is physical and abstract (as I 
> understand it). Physical URL ends up mapped onto a physical path on 
> the disk (by apache), and therefor know where to load a .htaccess file 
> (and the document), but an abstract ends up in a PythonHandler, that 
> takes care of the rest.
> The abstract URL handler will only be able to load the .htaccess file 
> in the dir where it lives, but no config change depends on the URL, as 
> long as it ends up in our handler.
> Hmm, hope this makes sense. Anyway, I don't see any problems regarding 
> configuration and different URL's, but I may be missing somthing.

Yeah, makes sense. In Vampire, the PythonHandler is set to a module not 
in the directory hierarchy. It handles the dispatch against actual 
handlers in directory hierarchy. Because actual content handlers are 
over the directory hierarchy under the root managed by Vampire, the 
in sub directories come into play because there is still a physical 
with URL namespace and Apache just sorts it out the right way.

This probably doesn't make much sense they way I have explained it 
though. You
would really need to play with Vampire to understand.

Anyway, having explored this a but, am certainly going to implement 
such a
mechanism in Vampire.


More information about the Mod_python mailing list