[mod_python] Re: persistent, reliable globals

Whoops!  I forgot to mention, PythonImport is a server directive, so
it's only valid at server-scope.  E.g. not in Location or Directories.

B

On Mon, 8 Mar 2004, Ben wrote:

> Hello all,
>
> After grovelling mod_python, mod_perl, and Apache API docs, what i've
> discovered is this:
>
> If you just want to initialize a global variable, you can probably do
> that using the "PythonImport" directive.  in short:
>
> ServerName foo.com
> PythonPath "sys.path+['/path/to/MyGlobals']"
> PythonImport MyGlobals foo.com
>
> or something like this, depending on how you set the
> PythonInterpPerDirective/Directory settings.  PythonImport happens
> per-subinterpreter (not for the main interpreter, nor per-thread),
> inside of the apache per-child hook.  This of course will only be
> shared within a child process, within a named subinterpreter.  There
> are good docs on how it is used in the mod_python manuals.
>
> More examples:
>
> PythonInterpPerDirective
> <Directory /mydir>
> 	AddHandler mod_python .py
> 	PythonHandler mod_python.publisher
> 	PythonPath "sys.path+['/path/to/MyGlobals']"
> 	PythonImport MyGlobals /mydir
> </Directory>
>
> OR
>
> # Creates a subinterpreter "MyInterpreter" which handles the
> # requests in this scope to be run there
> PythonInterpreter MyInterpreter
> PythonPath "sys.path+['/path/to/MyGlobals']"
> PythonImport MyGlobals MyInterpreter
>
> There are some caveats, however:
>
> 1) The imports happen at child initialization time, when a lot of the
> configuration hasn't been merged in yet.  This includes:
> PythonInterpreter (!!!), PythonOptions, ....
>
> 2) PythonImport is not really subinterpreter-scoped: it is a global
> directive that specifies the interpreter name.  Plus PythonInterpreter
> isn't in effect at the time of import, either.  It would be nice to
> have a directive like
>
> PythonInterpInit Foo
>
> which would affect the interpreter "in the current scope" in the
> apache configuration -- i.e. at the virtual server level by default,
> or per directive / directory if those options are used.
>
> 3) This is not entirely specific to PythonImport, but it is difficult
> in general to get your hands on configuration variables
> (PythonOption-s, in particular) not in the context of a request.  It
> would be nice if each subinterpreter had access to the Apache
> configuration variables (e.g. PythonOptions) scope-local to it.
>
> As a workaround, I'm using named interpreters and moving all
> sub-interpreter-specific configuration into importable files.
>
> 4) Running with PythonAutoReload may still kill global variables if
> you're not careful.
>
> B
>
> ps put this into the FAQ?
>
> On Mon, 8 Mar 2004, Ben wrote:
>
> > Hello,
> >
> > it seems like this is a question that is asked enough to be worth
> >
> > a) putting into the FAQ (for now), and
> > b) eventually trying to solve.
> >
> > i used to do some apache API coding so i'd be willing to look into
> > trying to support per-child (and possibly per-thread) initialization
> > code.  i remember this used to be possible, and looking at mod_perl i
> > see it has a PerlChildExitHandler.
> >
> > http://perl.apache.org/docs/2.0/user/handlers/server.html
> >
> > i'll start code-diving today, and let people know what i find.  (oh
> > woe to the python programmer who has to read C!)
> >
> > take care, B
> >
> > ps i happen to want this for my project, which is an object / aspect
> > oriented servlet framework, that supports mixin-style functionality
> > for session-based authentication, caching, etc.  i plan on releasing
> > that too, after some bugfixes and documentation.
>
>
>