Re: [Web-SIG] WSGI in standard library

2006-02-16 Thread Alan Kennedy
[Ian Bicking] Anyway, I'm +1 on the object [wsgiref's wsgi header manipulation class] going somewhere. I don't know if the parent package has to be named wsgi -- and wsgiref seems even stranger to me, as anything in the standard library isn't a reference implementation anymore, but an actual

Re: [Web-SIG] WSGI in standard library

2006-02-16 Thread Alan Kennedy
[Guido Van Rossum] Actually BaseHTTPServer.py and friends use a deprecated naming scheme -- just as StringIO, UserDict and many other fine standard library modules. If you read PEP 8, the current best practice is for module names to be all-lowercase and *different* from the class name.

Re: [Web-SIG] WSGI in standard library

2006-02-16 Thread Bill Janssen
Thinking about this some more, it's beginning to sound to me like the server-side web support in the standard library needs a proper review and possible rework: it's slowly decohering/kipplizing. Maybe we need a PEP, so that we can all discuss the subject (rationally ;-) and sort out all of

Re: [Web-SIG] WSGI in standard library

2006-02-16 Thread Ian Bicking
Bill Janssen wrote: I think John Lee has done some work on this? Beats me. I've never felt any need for CSS parsing personally. If you are doing any work with the Web (spidering, for instance), and need to do rendering of the Web pages (say, for pop-out prism, or building an ebook

Re: [Web-SIG] WSGI in standard library

2006-02-16 Thread Ian Bicking
Bill Janssen wrote: What would we be PEPing? Well, when we started, I made up a list of various things that seem to be missing in the standard library, like server-side support for SSL-encrypted socket connections. http://www.parc.com/janssen/web-sig/needed.html Here's my thoughts on