[Web-SIG] PEP 444 Goals
Alice Bevan–McGregor
alice at gothcandy.com
Thu Jan 6 21:52:29 CET 2011
> 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.
More information about the Web-SIG
mailing list