You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2006/03/11 01:36:54 UTC

[jira] Commented: (MODPYTHON-118) Allow PythonImport to optionally call function in module.

    [ http://issues.apache.org/jira/browse/MODPYTHON-118?page=comments#action_12369947 ] 

Graham Dumpleton commented on MODPYTHON-118:
--------------------------------------------

It might also be appropriate that the function that can be registered to be called be passed a single argument which is the "server" object. Ie., same as "req.server" that request handlers have access to. This would give access to "server.get_options()" and other information about the server.This though means that you would have to wrap existing methods with no argument that weren't interested in the "server" object.

Alternatively, go with no argument as proposed, but the "apache._server" and "apache._interpreter" attributes be renamed to "apache.server" and "apache.interpreter" and be officially sanctioned as part of the public API of mod_python. Being public, they would then also be useable from global scope within any module which has been imported. This is probably a preferable path to take.

> Allow PythonImport to optionally call function in module.
> ---------------------------------------------------------
>
>          Key: MODPYTHON-118
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-118
>      Project: mod_python
>         Type: Wish
>   Components: core
>     Versions: 3.3
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton

>
> PythonImport can currently be used to specify that a module be imported into a named interpreter at the time that an Apache child process is initiated. Because all it does is import the module, if any specific action needs to be triggered, it has to be done as a side effect of the module import.
> Triggering  actions as a side effect of a module import is generally not a good idea as failure of the side effect action will cause the import of the module itself to fail if the code doesn't properly handle this situation. It is generally preferable to import the module and when that has suceeded only then call a specific function contained in the module to initiate the action.
> Thus proposed that PythonImport be able to take an optional function to be called upon successful import of the name module. The syntax would be like that for Python*Handler directives.
>   PythonImport mymodule::myfunc myinterpreter
> This would have the effect of loading module "mymodule" in the interpreter called "myinterpreter" and then calling "mymodule.myfunc()". No arguments would be supplied to the function when called.
> Another benefit of this feature would be that it would allow a single module to be able to contain a number of special initialisation functions that might be triggerable. The user could selectively call those that might be required.
>   PythonImport mymodule::enable_caching myinterpreter
>   PythonImport mymodule::disable_logging myinterpreter
> At the moment to do that, a distinct module would need to be created for each where the only thing in the module is the call of the function.
> Note that in using something similar to mod_python option/config values, am talking here about options that must be able to only be enabled/disable in one spot. The problem with mod_python option/config values in Apache is that different parts of the document tree can set them to different values, which for some things is actually a problem, such as the case with PythonAutoReload.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira