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