[Web-SIG] Re: WSGI and Configuration

[Ian Bicking]

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 
> nice?)

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 
(py.path.local.local.LocalPath.getpycodeobj and 
py.path.common.FSPathBase.getpymodule).

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