[Web-SIG] PEP 444 Goals

[P.J. Eby]

At 01:17 AM 1/7/2011 -0800, Alice Bevan­McGregor wrote:
>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 meant that if a server doesn't implement the spec because of a 
required feature, then the app developer doesn't have the option of 
using that feature anyway -- meaning that adding the feature to the 
spec didn't really help.


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

The reason I proposed the 3-tuple return in the first place (see 
http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html 
) was that I wanted to make middleware *easy* to write.

Easy enough to write quick, say, 10-line utility functions that are 
correct middleware -- so that you could actually build your 
application out of WSGI functions calling other WSGI-based functions.

The yielding thing wouldn't work for that at all.


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

So, in order to know what type each CGI variable is, you'll need a reference?


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

I mean the ones required by the spec, not server-specific extensions.



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

No, otherwise I'd totally go for the surrogateescape approach.  Heck, 
I'd still go for it if it were possible to write a surrogateescape 
handler for 2.6, and require that a PEP 444 server register one with 
Python's codec system.  I don't know if it's *possible*, though, 
hopefully someone with more knowledge can weigh in on that.


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

I'm just asking whether, in your statement of goals and rationale, 
you would expand "cross compatibility" as meaning cross-python 
version portability, or whether you meant something else.