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