[Web-SIG] PEP 444 Goals

[P.J. Eby]

At 12:52 PM 1/6/2011 -0800, Alice Bevan­McGregor wrote:
>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]

A big +1 to all the above as goals.


>:: Reduction of re-implementation / NIH syndrome by incorporating 
>the most common (1%) of features most often relegated to middleware 
>or functional helpers.

Note that nearly every application-friendly feature you add will 
increase the burden on both server developers and middleware 
developers, which ironically means that application developers 
actually end up with fewer options.


>   Unicode decoding of a small handful of values (CGI values that 
> pull from the request URI) is the biggest example. [2, 3]

Does that mean you plan to make the other values bytes, then?  Or 
will they be unicode-y-bytes as well?  What happens for additional 
server-provided variables?

The PEP 3333 choice was for uniformity.  At one point, I advocated 
simply using surrogateescape coding, but this couldn't be made 
uniform across Python versions and maintain compatibility.

Unfortunately, even with the move to 2.6+, this problem remains, 
unless server providers are required to register a surrogateescape 
error handler -- which I'm not even sure can be done in Python 2.x.


>:: Cross-compatibility considerations.  The definition and use of 
>native strings vs. byte strings is the biggest example of this in the rewrite.

I'm not sure what you mean here.  Do you mean "portability of WSGI 2 
code samples across Python versions (esp. 2.x vs. 3.x)?"