At 12:52 PM 1/6/2011 -0800, Alice BevanMcGregor 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)?"
_______________________________________________
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
