[mod_python] PythonOption access

Graham Dumpleton wrote:

>Having a bit more of a think about this, it wouldn't be too hard for me to
>implement a relatively clean mechanism which would allow access to the
>request object when loading a module, in the Vampire package I provide.
>  
>
First, thanks for all the input ...

I am not aware of what the "Vampire" module are, one of Your projects ?

>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 ?

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

>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 ?

>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 :-)

>Is this the sort of thing you were wanting, or have I misunderstood?
>  
>
Yeps, with some corrections :-)

>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 :-)

>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 :-)

>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.

>Anyway, worth thinking about some more.
>  
>
Nice.

Anyway, python is a fantastic web script if you like your code to be 
readable :-)

/BL