Re: [Web-SIG] wsgiref for python 2.4?
http://pypi.python.org/pypi/wsgiref It wouldn't hurt to look at CherryPy's WSGIServer anyway. I think it's generally a lot more efficient/scalable than the BaseHTTPServer-based implementation in wsgiref, and it's reasonably lightweight (one .py file, 1311 lines). http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver/__init__.py On 7 Feb 2008, at 11:48, Chris Withers wrote: Hi All, The subject line kindof says it all, but is there a wsgiref for python 2.4? Failing that, what's the lightest-weight wesgi server available for python 2.4? cheers, Chris ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] a possible error in the WSGI spec
On 20 Dec 2007, at 07:27, Manlio Perillo wrote: What's wrong is that the invocation of start_response may be performed at any iteration of the iterable, as long as the application yields empty strings. In what context? I suspect that's an error in a particular implementation, not in the spec. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] app iterable containing non-strings
The spec says Regardless of how it is accomplished, the application object must always return an iterable yielding zero or more strings. The must means that anything else should be considered an error (I think). If your middleware does anything to the iterated strings, then you'll have to catch non-strings and raise the error yourself, but otherwise, it's not your middleware's business, and I'd say it should be left to the gateway (or any other lower point in the WSGI stack that happens to notice it). On 16 Dec 2007, at 01:10, Ionel Maries Cristian wrote: I was reading the wsgi spec and i was wondering how should middleware treat the iterable that happens to contain values that aren't strings (and I'm not talking about unicodes) - the spec isn't explicit on this. If middleware would just pass on values that aren't string instances - this could be a mechanism for server extensions. (besides the environ) -- http://code.google.com/p/cogen/ ionel. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/adam%40atlas.st ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WSGI, Python 3 and Unicode
On 6 Dec 2007, at 18:13, Graham Dumpleton wrote: In Python 3 the default for string type objects will effectively be Unicode. Is WSGI going to be made to somehow cope with that, or will application instead be required to return byte string objects instead? I'd say it would be best to only accept `bytes` objects; anything else would require some guesswork. Maybe, at most, it could try to encode returned Unicode objects as ISO-8859-1, and have it be an error if that's not possible. I was going to say that the gateway could accept Unicode objects if the user-agent sent a comprehensible Accept-Charset header, and thereby encode application output to the client's preferred character set on the fly (or to ISO-8859-1 if no Accept-Charset is provided), but that would complicate things for people writing gateways (and would be too implicit). It could be useful, but it would make more sense as a simple decorator for (almost-)WSGI applications. Perhaps it could go in wsgiref. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
