[Web-SIG] PEP222 and python on the server?

[Iwan Vosloo]

Ian Bicking <ianb at colorstudy.com> writes:
> Hope you don't mind, I copied this bad to web-sig...

Yea, sorry, that was the intention...

> Well, no one is going to argue that WSGI give pretty objects to work
> with.  WSGI is very thorough and non-limiting.  It also avoids any
> discussion of mixed case vs. underscores, and other details which are
> hard to decide on, while also being quite unproductive.  I think of it
> as being aesthetically neutral.  There's some other useful aspects of
> it as well.

True..

> *But*, you shouldn't program directly to it, unless you are trying to
> be framework neutral (or maybe really low level), and even then it
> isn't always necessary.  So it's expected there should be wrappers;
> especially request wrappers, but response wrappers are also fine (but
> they do interupt the call sequence a little in comparison to request
> wrappers).

Mmm, this is a bit outside of my main focus, so I'd have to have a better look at it - I understand, and those wrappers can be very very thin also.  The only point I would like to make is that it is very useful to glue several frameworks together to accomplish a task.  And they often communicate via request and response instances.  I'll have to do more homework and try to make a better case for it.

>> Regarding the WSGI - are there plans to have an implementation of it
>> in the standard library?
>
> No, there aren't any plans.  I wasn't really sure what would go in the
> standard library, though now I'm thinking it would be really good to
> get some stuff in there.  In particular, I'd like to see
> SimpleHTTPServer extended to do WSGI, and a WSGI server added to cgi.
> I don't know how practical it is to add new servers to the standard
> library, but the ones that are already there could definitely support
> it.  On the application side the cgi library mostly is sufficient,
> though it could probably use some relevant examples and documentation
> -- right now you have to read the source of that module to get the
> full FieldStorage signature.

Definately a good idea to get some stuff in there, I think.  Some people are publishing implementations of WSGI compliant code in single files on their websites, others grab these, modify them - and you end up getting several mutations of the same thing installed by different packaged products...

And FieldStorage is also not the prettiest thing in the world :-)!  (But I'm happy its there..)

-i