[Web-SIG] PEP 444 Goals

[Alice Bevan–McGregor]

> 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.