Please ensure you have also all read: http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html
I will post again later in detail when have some time to explain a few more points not mentioned in that post and where people aren't quite understanding the reasoning for doing things. One very quick comment about read(). Allowing read() with no argument is no different to a user saying read(environ['CONTENT_LENGTH']). Because a WSGI adapter/middleware is going to have to track bytes read to ensure can return an empty string as end sentinel, it will know length remaining and would internally for read() with no argument do read(remaining_bytes). As such no real differences in inefficiencies as far as memory use goes for implementing read() because of need to implement end sentinel. Also, you have concerns about read() with no argument, but frankly readline() with no argument, which is already required, is much worse because you cant really track bytes read and just read to end of input. This is because they only want to read to end of line and so reading all input is going to blow out memory use unreasonably as you speculate for read(). As such, a readline() implementation is likely to read in blocks and internally buffer where read() doesn't necessarily have to. It may also be pertinent to read: http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html as from memory it talks about issues with not paying attention to Content-Length on output filtering middleware as well. As I said, will reply later when have some time to focus. Right now I have a 2 year old to keep amused. Graham 2009/11/27 James Y Knight <[email protected]>: > I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the official > definition of WSGI 1.1, which describes how to implement WSGI adapters for > both Python 2.x and 3.x. It may not be perfect, but, it's been implemented > twice, and seems ot have no fatal flaws (it doesn't do any lossy transforms, > so any issues are irritations at worst). The basis for this definition is > also described in the "WSGI 1.0 Ammendments" [2] page. > > The definitions as they stand are clear enough to understand and implement, > but not currently in spec-worthy language. (e.g. it says "should" and "may" > in a colloquial fashion, but actually means MUST in some places and SHOULD in > others, as defined by RFC 2119) > > Thus, I'd like to suggest that Graham (if he's willing?) should reformat the > "Definition"/"Ammendments" as an actual diff against the current PEP 333. > Then, I will recommend adopting that document as an actual standard WSGI 1.1, > to replace PEP 333. > > This discussion has gone on long enough, and it doesn't really matter as much > to have the perfect API, as it does to have a standard. > > James > > [1] http://code.google.com/p/modwsgi/wiki/SupportForPython3X > [2] http://www.wsgi.org/wsgi/Amendments_1.0 > > _______________________________________________ > Web-SIG mailing list > [email protected] > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com > _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
