At 11:56 AM 10/24/2006 -0500, Ian Bicking wrote: >That would be a landing place for an implementation of this library code >that does what the spec implies. But it relies on the release cycle for >wsgiref, which is unclear and probably very slow since it is in the stdlib.
Not really. wsgiref is distributed standalone from the cheeseshop, so newer versions are just an easy_install away. >I have nothing against this being in wsgiref, I just would like to use >this convention sooner rather than later. Of course; the wsgiref thing was just a suggestion for where canonical implementations of these things would live. >>>Would you +1 the proposal if it is added that middleware does not destroy >>>the wsgi.input variable but clones it? >>I didn't -1 the proposal, I -1'd middleware. And the -1 >>stands. Middleware is absolutely not the place for adding derivative >>environ keys like this. It's 100% unnecessary, adds complexity, and >>reduces performance in the process. > >Please respond to my proposal, which as I've clarified does not imply any >particular middleware. You should clarify that in the proposal itself, explicitly forbidding it from being done by middleware unless the middleware is taking responsibility for request processing, or the middleware clones the environ. Too many people, upon first encountering WSGI middleware, want to use it to add things to the request API, when it isn't necessary. Notice Hans Then's reaction to my -1 on middleware, for example. Writing correct middleware is already difficult, let's not encourage people to write more incorrect middleware by increasing the temptation to use middleware for trivial API enhancements that would be better done as libraries. (Yes, I know that wasn't your intent, but at least one person besides me interpreted it as such.) As far as the other open issues in the proposal, I don't really care much. My main concern is making sure that the proposal doesn't encourage people to start creating middleware whose sole purpose is to add unnecessary junk to environ while breaking other applications as a side effect. :) (I do suggest, however, that a simpler way to assure WSGI compliance when removing wsgi.input may be to set the incoming content-length to zero. An application or library that tries to read wsgi.input when the content length is zero is itself non-compliant.) _______________________________________________ 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
