[Web-SIG] Future of WSGI
I disagree that the current 1.x track of the WSGI specification [1] supports Python 3 in any reasonable way. Recently I suggested the following rule as a guideline [2]: Strings should be strings, chunks should be bytes. What this really suggests is that everything that looks and feels like a human-readable string (almost everything in HTTP except the input content and the output response) should be a (unicode) string. As I read the proposed 1.1 revision, this is not the case. However, there is another fish to fry here too, and I'd like to propose a new 2.x track altogether. In the outset, this would pertain to Python 3 only. Instead of passing ``environ`` and violate its contract by adding 'wsgi.*' entries, we must pass in an object which actually represents the HTTP request, e.g. Request = namedtuple(Request, environ input) There could be other properties of this request-object. I haven't considered the details. To consider for this track is also the possibility of changing the application call signature (I heard this proposal from Daniel Holth, but it's probably been suggested before): def __call__(self, request): return status, headers, app_iter I don't mind ``start_response`` terribly, but it's worth discussing. Certainly returning this triple makes things easier. \malthe [1] http://bitbucket.org/ianb/wsgi-peps/src/tip/pep-0333.txt [2] http://mockit.blogspot.com/2009/11/dont-look-back-in-anger.html ___ 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
Re: [Web-SIG] Future of WSGI
On Tue, Nov 24, 2009 at 3:28 PM, Malthe Borch mbo...@gmail.com wrote: The proposal that seemed to work best was to keep the environ as str (i.e., unicode in Python 3), and eliminate the problematic SCRIPT_NAME and PATH_INFO, replacing them with url-encoded values. Also I think everyone is okay with removing start_response. All text would be decoded as latin1 on Python 3 (which allows for transcoding; also most text is not unicode). The request and response body would remain bytes. I assume with all text you mean all header text, e.g. all header values. All the things that are specified to be str, would stay str in Python 3. This includes all keys, headers, and stuff like wsgi.url_scheme. Can we talk briefly then about wsgi.*? I think we should eliminate them and in their place put a real request object, something very basic that has only what's absolutely necessary to communicate the essential data from the low-level HTTP request. There is no way that the environment can express an HTTP request. This was a mistake in my view and we should rectify it either in 1.1 or 2.0. I'm not aware of any problems with representing the request with a dictionary. Can you give examples? -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ 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
Re: [Web-SIG] Future of WSGI
On Tue, Nov 24, 2009 at 3:40 PM, Malthe Borch mbo...@gmail.com wrote: I'm not aware of any problems with representing the request with a dictionary. Can you give examples? The body stream is not part of the HTTP environment. It's an abuse and it has the very negative effect of luring developers into further abuse. You mean specifically environ['wsgi.input'] ? While the file-like interface is difficult, other possible interfaces aren't so great either. As to putting the request body in the environment, I don't know what the problem is? Or are you just concerned that people put arbitrary things in the environ? There's far too many important use cases that are satisfied by the extensible nature of the environ to give it up just because some people believe it is overused. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ 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
Re: [Web-SIG] Future of WSGI
On Tue, Nov 24, 2009 at 4:16 PM, Sylvain Hellegouarch s...@defuze.org wrote: I'm not aware of any problems with representing the request with a dictionary. Can you give examples? Though it shouldn't be considered as a problem, the fact that probably no existing framework actually use the raw dictionary (there is, in almost all cases, a wrapping into a friendlier object), one might wonder why keeping such a low level interface rather than directly provide a higher level interface is a good idea. After all creating those dictionaries for no good reason aside from sending them to the next layer which will map them into a WebOb, a yaro, a cherrypy request, or zope request, etc. seems slightly pointless (I'm not versed into Python internals, but doesn't it have also a cost of creating rather useless objects repeatedly like that?) I know WSGI tries hard not to force into one implementation but still... Well, that's hardly a trivial requirement, nor a trivial accomplishment. Also the dictionary is a complete and inspectable representation of the environment, divorced from any possible trickery on the part of frameworks. It's a common gateway between servers and frameworks, and can be used as a gateway between middleware and applications. And it's really fairly common for middleware to use the raw dictionary without any object involved. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker ___ 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
Re: [Web-SIG] Future of WSGI
On Tue, Nov 24, 2009 at 11:36:57PM +0100, Malthe Borch wrote: 2009/11/24 Henry Precheur he...@precheur.org: (See http://tools.ietf.org/html/rfc2616#section-5) The request body, the request method (GET, POST, ...), the request URL, the HTTP version are all in `environ`. That reference does not mention the environment. It's not an official term. Are you talking about PEP-333 or RFC 2616? namedtuple is Python 2.6+: WSGI can't use it. WSGI must work w/ older versions of Python. It was meant as illustration, but sure. Then what? Your proposal doesn't work. So let's forget about it and stick to dict? -- Henry Prêcheur ___ 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
Re: [Web-SIG] Future of WSGI
2009/11/24 Henry Precheur he...@precheur.org: Are you talking about PEP-333 or RFC 2616? RFC 2616, which you linked to. Then what? Your proposal doesn't work. So let's forget about it and stick to dict? class Request(object): ... class Response(object): ... Now, what do you mean by let's forget about it. Maybe what you want to say is: I'll forget about it and stick to dict – because that's what you know how to? I mean this congenially; but please don't patronize. \malthe ___ 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
Re: [Web-SIG] Future of WSGI
On Tue, Nov 24, 2009 at 11:16:05PM +0100, Sylvain Hellegouarch wrote: Though it shouldn't be considered as a problem, the fact that probably no existing framework actually use the raw dictionary (there is, in almost all cases, a wrapping into a friendlier object), one might wonder why keeping such a low level interface rather than directly provide a higher level interface is a good idea. After all creating those dictionaries for no good reason aside from sending them to the next layer which will map them into a WebOb, a yaro, a cherrypy request, or zope request, etc. seems slightly pointless 1. Would you say that POSIX is useless because there are lots of libraries and applications build on top of it? Why not implement those libraries and applications directly without using POSIX? 2. Guess what: WebOb, Werkzeug, Yaro, Django, CherryPy, and the others have a different interfaces for their Request/Response objects. Because for Request/Response there's hardly one-size fits all. There's certainly some common ground, but every framework has different needs. (I'm not versed into Python internals, but doesn't it have also a cost of creating rather useless objects repeatedly like that?) The dictionary is passed as a reference like every Python objects. So it doesn't cost anything to use it instead of an object. -- Henry Prêcheur ___ 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
Re: [Web-SIG] Future of WSGI
2009/11/25 Henry Precheur he...@precheur.org: Please replace '...' with actual code or at least some description of what it's doing. Lots of people have been trying to define a nice interface for these objects for YEARS. People who know a great deal about HTTP, and Python. And yet there's not a single implementation that's widely accepted as the best of breed. class Request(object): def __init__(self, stream): self.environ = read_headers_until_crlf(stream) self.stream = stream These headers are then general-header, request-header, entity-header. The stream is what remains. Ian argues that the stream is part of the environment since ``CONTENT_LENGTH`` is there. However, it is not always there. It is to be understood as a hint. Why is this a good separation? For two reasons: 1) Everybody else does it; 2) This stream should be handled carefully throughout the WSGI pipeline. Keeping it as a separate property helps to make this point clear. As an alternative to a trivial request class, I propose: (environ, stream, [start_response]) (It seems ``start_response`` might go out altogether in a revised specification in favor of returning a response tuple over an app iterable). \malthe ___ 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
Re: [Web-SIG] Future of WSGI
Please replace '...' with actual code or at least some description of what it's doing. Lots of people have been trying to define a nice interface for these objects for YEARS. People who know a great deal about HTTP, and Python. And yet there's not a single implementation that's widely accepted as the best of breed. Mostly because no such discussion ever took place. Everyone does its own recipe and yet most request interface actually offer a very similar API. If it wasn't for WSGI, most frameworks wouldn't even talk to each other yet. But since it's the time of what could be improved, it seemed right to suggest to do better there too. Now I don't have a proposal so I wouldn't be upset if the community simply says no (I can understand Ian's point in an earlier response) but the question is rather valid nonetheless. - Sylvain ___ 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
