On Wed, 2010-09-15 at 20:05 -0400, P.J. Eby wrote: > 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.
We can ditch everything concerning web3.async as far as I'm concerned. Ian has told me that this feature won't be liked by the async people anyway, as it doesnt have a trigger mechanism. > 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. I'm not concerned about which environment variables have it, but I would definitely like to be able to get at the "original" (non-%2F-decoded) path info somewhere. I'd be fine if PATH_INFO was just that, and get rid of web3.path_info. web3.script_name is probably just a mistake entirely. > 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. I'm very willing to drop web3.async entirely. It seems reasonable to do so. I should have done so before I mailed the spec, as I knew it would be unpopular. > 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. No worries, let's get rid of both, with the caveat that it's pretty essential (to me anyway) to be able to get at the non-%2F-encoded path somewhere. The most sensible thing to me would be to put it in PATH_INFO. As far as bytes vs. strings, whatever, we have to pick one. Bytes makes more sense to me. I'll leave it to the native-string and/or unicode people to create their own spec. - C _______________________________________________ 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
