[mod_python] PythonOption access

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:

   http://www.dscpl.com.au/projects/vampire

>> 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" 
module.
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 
entirely
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 
handler
then one can theoretically have common modules which are imported based 
on
different URL request. When doing a sub import though, one might not 
necessarily
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 
loaded
by the top level PythonHandler dispatcher as it would guarantee it is 
set.
In mod_python 3.1.X, get() can take a default parameter if not set, so 
could
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 
mechanism
and automatic search mechanisms to find inherited config. It has always 
been
a shortcoming that one could only do the config search from inside 
execution
of request handler as one need the req object. With the scheme talked 
about
here, I can extend ability to access the config during module import 
phase.

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:

   hlist
   interpreter
   server
   get_options()
   get_config()
   document_root()

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

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 
even
in the directory hierarchy. It handles the dispatch against actual 
content
handlers in directory hierarchy. Because actual content handlers are 
spread
over the directory hierarchy under the root managed by Vampire, the 
.htaccess
in sub directories come into play because there is still a physical 
correspondance
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.

Graham