[Web-SIG] Re: WSGI and Configuration
ianb at colorstudy.com
Sun Nov 14 14:46:23 CET 2004
Phillip J. Eby:
> *Shudder*. Ideally, a server would allow customizing sys.path at least
> long enough to import/setup the application. Otherwise, we lose out on
> being able to e.g. deploy an application in a zipfile. (Wouldn't that be
Eh. Unpacking files isn't that hard, is it? A lot easier than figuring
out sys.path, dealing with ambiguous names or name conflicts between
separate applications or components, etc. I hate sys.path. And the two
aren't mutually exclusive. I should look at py.path
(http://codespeak.net/py), as it has code along these lines
Importing from arbitrary locations is also necessary if Python web
programming is able to feel like some other kinds of web programming;
e.g., PHP/ASP. While I wouldn't advocate that for every application or
environment, I think it's a valid use case.
> I don't think PEAK's import tools really have much to offer here, unless
> you just mean the convenient 'importString()' function. Couple that with
> maybe some temporary additions to sys.path, and you're set.
I don't really think it'll work if they are temporary. Because sys.path
effects all imports (and worse, implicitly and inconsistently), messing
with it and then undoing that will cause confusion. I'd rather mangle
things from the beginning (e.g., name a module
'frompath.path_to_module'), at least that is predictable.
> Of course, of the Python web servers out there, I'm thinking only
> mod_python and modjy are really going to be able to handle this
> well. mod_python can run apps in separate interpreters, and each can have
> its own, completely transparent sys.path. modjy uses Jython, so in
> principle it could run apps in different interpreters, though I don't think
> it currently does.
I don't think anything but CGI can handle this. Since there's
persistent effects when you change sys.path (like modules left around
that are named according to the sys.path that was in effect when they
were imported), you could mess things up for later requests. And it
will be incredibly confusing when it happens.
> I *do* have a project on the back burner to make the CPython
> multi-interpreter API accessible from Python code, though. Indeed, I
> intend to write a PEP to propose standardizing a multi-interpreter API
> for CPython, Jython, IronPython, and indeed all Python
> implementations. But first, I'd like to finalize PEP 333. :)
I always wondered why the multiple interpreters weren't accessible from
Python code. But I can imagine that would open up a big can of worms...
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG