At 07:03 PM 9/15/2010 -0400, Chris McDonough wrote:
A PEP was submitted and accepted today for a WSGI successor protocol
named Web3:
http://python.org/dev/peps/pep-0444/
I'd encourage other folks to suggest improvements to that spec or to
submit a competing spec, so we can get WSGI-on-Python3 settled soon.
The first thing I notice is that web3.async appears to force all
existing middleware to delete it from the environment if it wishes to
remain compatible, unless it adapts to support receiving callables itself.
On further reading I see you have something about middleware
disabling itself if it doesn't support async execution, but this
doesn't make any sense to me: if it can't support async execution,
why wouldn't it just delete web3.async from the environ, forcing its
wrapped app to be synchronous instead?
I'm also not a fan of the bytes environ, or the new
path_info/script_name variables; note that the spec's sample CGI
implementation does not itself provide the new variables, and that
middleware must be explicitly written to handle the case where there
is duplication.
My main fear with this spec is that people will assume they can just
make a few superficial changes to run WSGI code on it, when in fact
it is deeply incompatible where middleware is concerned. In fact,
AFAICT, it seems like it will be *harder* to write correct web3
middleware than it is to write correct WSGI middleware now.
This seems like a step backward, since the whole idea behind dropping
start_response() was to make correct middleware *easier* to write.
Any time a spec makes something optional or allows More Than One Way
To Do It, it immediately doubles the mimimum code required to
implement that portion of the spec in compliant middleware. This
spec has two optionalities: web3.async, and the optional
path_info/script_name, so the return handling of every piece of
middleware is doubled (or else "environ['web3.async'] = False" must
be added at the top), and any code that modifies paths must similarly
ditch the special variables or do double work to update them.
_______________________________________________
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
