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