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