[Web-SIG] PEP 444 (aka Web3)

[P.J. Eby]

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.