Re: PEP 444 Goals

On 2011-01-07 08:28:15 -0800, P.J. Eby said:
> 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 
> arequired 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 truly can not worry about non-conformant applications, middleware, or 
servers and still keep my hair.

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

This was noted several times, and I do agree with that blog article 
which states that a lot of middleware shouldn't be middleware.

> Easy enough to write quick, say, 10-line utility functions that 
> arecorrect middleware -- so that you could actually build 
> yourapplication out of WSGI functions calling other WSGI-based 
> functions.
> 
> The yielding thing wouldn't work for that at all.

Handling a possible generator isn't that difficult.

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

Reference?  Re-read what I wrote.  Only URI-specific values utilize an 
encoding reference variable in the environment; that's four values out 
of the entire environ.  There is one, clearly defined bytes value.  The 
rest are native strings, decoded using 
latin1/iso-8859-1/"str-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.)
> 
> I mean the ones required by the spec, not server-specific extensions.

The spec clearly defines the expected value types (see above).  If it 
doesn't, I will fix that.  ;)

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

Cross-Python version portability is what it was intended to mean.

	- Alice.


_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org