Graham Dumpleton
grahamd at dscpl.com.au
Thu Jan 20 19:54:43 EST 2005
Bo Lorentsen wrote .. > Will it be possible to access PythonOptions like log_error in a more > global context (log_error is a function on the apache module), so that > global values can get there init value on module init and NOT on the > first incomming request ? I have some code that work around this, but > its not pretty, and I like things to be so, and I don't understand why > it has to be a method on the request module. > > Is this completely impossible ? 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. In Vampire, it uses its own module caching and import system and thus I have more control over this process. At the moment the prototype for the module import function is "importModule(name,path)". That is, the input arguments are the name of the module, and the specific directory in which that module is expected to be located. The module importing mechanism in Vampire doesn't use the "imp" module and instead uses "execfile()". As such, the code already creates a module object into which the code file is executed in order to achieve the same affect as an import. Ie., module = imp.new_module(label) module.__file__ = file execfile(file,module.__dict__) 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__"] The only other change would be where the code uses the import function to load in content handlers, it would need to pass req. 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. 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(...) Is this the sort of thing you were wanting, or have I misunderstood? Overall I am not sure that this is a good idea or not. It has both good points and bad points. 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. 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. Anyway, worth thinking about some more. Graham
|