It seems to me that the spec that Alice is working on could be
something great but the problems are not well defined (in the PEP).
This causes confusion about what the goals are.
For completeness sake, here's a slightly simplified Abstract:
:: A proposed second-generation standard interface between web servers
and Python 2.6+ and 3.1+ applications.
The rationale for even having such an interface is outlined in PEP 333.
Ignoring async for the moment, the goals of the PEP 444 rewrite are:
:: Clear separation of "narrative" from "rules to be followed". This
allows developers of both servers and applications to easily run
through a confomance "check list".
:: Isolation of examples and rationale to improve readability of the
core rulesets.
:: Clarification of often mis-interpreted rules from PEP 333 (and those
carried over in 3333).
:: Elimination of unintentional non-conformance, esp. re: cgi.FieldStorage.
:: Massive simplification of call flow. Replacing start_response with
a returned 3-tuple immensely simplifies the task of middleware that
needs to capture HTTP status or manipulate (or even examine) response
headers. [1]
:: Reduction of re-implementation / NIH syndrome by incorporating the
most common (1%) of features most often relegated to middleware or
functional helpers. Unicode decoding of a small handful of values (CGI
values that pull from the request URI) is the biggest example. [2, 3]
:: Cross-compatibility considerations. The definition and use of
native strings vs. byte strings is the biggest example of this in the
rewrite.
:: Making optional (and thus rarely-implemented) features non-optional.
E.g. server support for HTTP/1.1 with clarifications for interfacing
applications to 1.1 servers. Thus pipelining, chunked encoding, et.
al. as per the HTTP 1.1 RFC.
There are likely others I can't think of at the moment. ;) If I
remember anything else as I wake up more fully (caffeine zombie, here)
I'll post an additional reply.
Footnotes:
[1] This also happens to be a very Pythonic solution.
[2] This does not mean WSGI 2 will attempt to "compete" with
frameworks; merely reduce the multiplication of effort for the common
denominator.
[3] Filters are covered under re-implementation.
Since Alice is rewriting the PEP perhaps we should all sit back for a
second until we have a PEP to work off of. That will help the
discussion be a little more focused.
I'll have a direct translation of my current rewritten draft into ReST
for incorporation on the Python.org website within a few hours.
Unfortunately, in the short term, it still doesn't include a high-level
goal overview, though will incorporate the consensus (thus far) on
removing the ability to return unicode response data.
Sorry if I've stepped on anyone's toes.
No worries; you do raise a very valid point.
- Alice.
_______________________________________________
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
