[mod_python] PythonImport: Can someone please draw a diagram for this idiot?

Jim Gallacher jg.lists at sympatico.ca
Thu Sep 15 00:09:35 EDT 2005


Jorey Bump wrote:
> Jorey Bump wrote:
> 
>> Jim Gallacher wrote:
>>
>>> I don't know if this is the correct way, but I tried it and it works:
>>>
>>> import sys
>>> mpglobal = sys.modules['mpglobal']
>>>
>>> def index(req):
>>>     req.write('Hello world\n')
>>>     req.write(mpglobal.foo)
>>
>>
>>
>> That's very interesting, because due to module caching, the results 
>> are the same if you simply do this:
>>
>> import mpglobal
>>
>> In the published module, when mpglobal is imported, /tmp/atest isn't 
>> updated and mpglobal.foo is available, indicating that one could 
>> initialize a db connection or variables using PythonImport, yet ensure 
>> the module will still work if sys.modules['mpglobal'] isn't available.
> 
> 
> OK, this allows for a simpler test:
> 
> # mpglobal.py
> # import this with PythonImport
> import time
> foo = time.strftime('%X %x %Z')
> 
> Published module:
> 
> # globaltest.py
> # access global module without reimporting, due to module caching
> import mpglobal
> def index():
>     return mpglobal.foo
> 
> Visit:
> 
>  http://host/somedir/globaltest/
> 
> This will display the time the module was originally imported. Due to 
> module caching, the same time will be displayed for multiple requests, 
> but eventually the module will be reimported as new child processes 
> begin, and different times will be displayed (use multiple browsers to 
> see the effect best). This is consistent with the documentation.
> 
> As far as I can tell, PythonImport doesn't provide any more persistence 
> for dynamically created objects or globals than simply importing the 
> module directly in a published module. The documentation implies that 
> this directive is mainly useful for initializing time consuming tasks 
> before the first request. But isn't that only true directly after 
> (re)starting apache? Isn't it the case that subsequent requests cause 
> apache to spawn more children, thus reintroducing the delay for the 
> first request in that child process?

I think this is all true.  You don't gain much by using it, especially 
for mpm-prefork.

Jim


More information about the Mod_python mailing list