[Web-SIG] PEP 444 Goals

[Alice Bevan–McGregor]

On 2011-01-06 20:18:12 -0800, P.J. Eby said:
>> :: 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.

Some things shouldn't have multiple options in the first place.  ;)  I 
definitely consider implementation overhead on server, middleware, and 
application authors to be important.

As an example, if yield syntax is allowable for application objects (as 
it is for response bodies) middleware will need to iterate over the 
application, yielding up-stream anything that isn't a 3-tuple.  When it 
encounters a 3-tuple, the middleware can do its thing.  If the app 
yield semantics are required (which may be a good idea for consistency 
and simplicity sake if we head down this path) then async-aware 
middleware can be implemented as a generator regardless of the 
downstream (wrapped) application's implementation. That's not too much 
overhead, IMHO.

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

Specific CGI values are bytes (one, I believe), specific ones are true 
unicode (URI-related values) and decoded using a configurable encoding 
with a fallback to "bytes in unicode" (iso-8859-1/latin1), are kept 
internally consistent (if any one fails, treat as if they all failed), 
have the encoding used recorded in the environ, and all others are 
native strings ("bytes in unicode" where native strings are unicode).

> What happens for additional server-provided variables?

That is the domain of the server to document, though native strings 
would be nice.  (The PEP only covers CGI 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.

As an open question to anyone: is surrogateescape availabe in Python 
2.6?  Mandating that as a minimum version for PEP 444 has yielded 
benefits in terms of back-ported features and syntax, like b''.

>> :: 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 
> 2code samples across Python versions (esp. 2.x vs. 3.x)?"

It should be possible (and currently is, as demonstrated by 
marrow.server.http) to create a polygot server, polygot 
middleware/filters (demonstrated by marrow.wsgi.egress.compression), 
and polygot applications, though obviously polygot code demands the 
"lowest common denominator" in terms of feature use.  Application / 
framework authors would likely create Python 3 specific WSGI 
applications to make use of the full Python 3 feature set, with 
cross-compatibility relegated to server and middleware authors.

	- Alice.