[Web-SIG] PEP 444 Goals
Alice Bevan–McGregor
alice at gothcandy.com
Fri Jan 7 22:22:23 CET 2011
On 2011-01-07 08:28:15 -0800, P.J. Eby said:
> At 01:17 AM 1/7/2011 -0800, Alice BevanMcGregor 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.
More information about the Web-SIG
mailing list