From mborch at gmail.com Wed Nov 18 12:45:40 2009 From: mborch at gmail.com (Malthe Borch) Date: Wed, 18 Nov 2009 12:45:40 +0100 Subject: [Web-SIG] Announcing bobo In-Reply-To: <4A38B382.3050700@simplistix.co.uk> References: <3131A7CA-E0D6-49B9-A84F-56C91F82E958@zope.com> <4A38B382.3050700@simplistix.co.uk> Message-ID: <4B03DE64.8060600@gmail.com> On 6/17/09 11:12 AM, Chris Withers wrote: > Do you know if there are plans/possibilities to make the routing part of > Bobo available for other frameworks and/or in a non-decorator fashion? FWIW, a bobo/bfg-compatible router is provided with Otto [1]. It borrows some code from bobo, but is slightly more versatile. Same (good) performance. - [1] http://www.ottohttp.org/docs/1.2/ From manders2k.dev at gmail.com Thu Nov 19 23:29:40 2009 From: manders2k.dev at gmail.com (Matt Anderson) Date: Thu, 19 Nov 2009 16:29:40 -0600 Subject: [Web-SIG] announcing 'httpmessage' Message-ID: Hello all -- A few months ago I found myself wanting to write an HTTP proxy. I surveyed the standard library and pypi for a good foundation on which to build such a thing, and I didn't find (or failed to recognize) anything particularly well suited to being that foundation. Admittedly, I didn't really look *that* hard, as I wanted to better learn low level network / web programming anyway. After a couple of false starts, I've ended up with a package I called 'httpmessage'. I've made it available at: http://code.google.com/p/httpmessage/ It's my first open source software release. I imagine it might be useful to other people, so I spent some extra time putting a little polish on the documentation. It's essentially a low level http library, modeling an HTTP message as a dict-like/file-like object hybrid. Dict-api for raw-header access, file-like-api for raw entity access, and a plethora of descriptors for higher-level header access. It knows how to read HTTP messages from a file-like object or socket data source. It tries not to make an assumption that you are programming a web client or a web server, just that you want to communicate via HTTP. It isn't extensively tested, isn't that mature, isn't covered by unit tests (I'm starting to work on that now) and a few things are even still missing. Yes, a glowing endorsement ;-). But it's developed to the point where I find it to be useful. Others might too. Comments, feedback, suggestions welcome. -- Matt Anderson From jim at zope.com Thu Nov 19 23:43:15 2009 From: jim at zope.com (Jim Fulton) Date: Thu, 19 Nov 2009 17:43:15 -0500 Subject: [Web-SIG] announcing 'httpmessage' In-Reply-To: References: Message-ID: <1099b90b0911191443u28a92dd0raa3d33bbae21cb98@mail.gmail.com> On Thu, Nov 19, 2009 at 5:29 PM, Matt Anderson wrote: > Hello all -- > > A few months ago I found myself wanting to write an HTTP proxy. ?I surveyed > the standard library and pypi for a good foundation on which to build such a > thing, and I didn't find (or failed to recognize) anything particularly well > suited to being that foundation. ?Admittedly, I didn't really look *that* > hard, as I wanted to better learn low level network / web programming > anyway. > > After a couple of false starts, I've ended up with a package I called > 'httpmessage'. ?I've made it available at: > > ?http://code.google.com/p/httpmessage/ > > It's my first open source software release. I imagine it might be useful to > other people, so I spent some extra time putting a little polish on the > documentation. > > It's essentially a low level http library, modeling an HTTP message as a > dict-like/file-like object hybrid. ?Dict-api for raw-header access, > file-like-api for raw entity access, and a plethora of descriptors for > higher-level header access. ?It knows how to read HTTP messages from a > file-like object or socket data source. ?It tries not to make an assumption > that you are programming a web client or a web server, just that you want to > communicate via HTTP. > > It isn't extensively tested, isn't that mature, isn't covered by unit tests > (I'm starting to work on that now) and a few things are even still missing. > ?Yes, a glowing endorsement ;-). ?But it's developed to the point where I > find it to be useful. ?Others might too. > > Comments, feedback, suggestions welcome. If I understand what this is, a library for dealing with HTTP messages *without* being tied to any particular networking approach or library, then this is something I've been wanting to see someone do well for some time. Good luck! Jim -- Jim Fulton From mborch at gmail.com Tue Nov 24 09:58:24 2009 From: mborch at gmail.com (Malthe Borch) Date: Tue, 24 Nov 2009 09:58:24 +0100 Subject: [Web-SIG] Future of WSGI Message-ID: <4B0BA030.5010201@gmail.com> 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 From ianb at colorstudy.com Tue Nov 24 18:44:56 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 24 Nov 2009 11:44:56 -0600 Subject: [Web-SIG] Future of WSGI In-Reply-To: <4B0BA030.5010201@gmail.com> References: <4B0BA030.5010201@gmail.com> Message-ID: Have you read the threads on WSGI 2? These issues are discussed at length, though they haven't been put into a spec. 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. On Tue, Nov 24, 2009 at 2:58 AM, Malthe Borch wrote: > 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 at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/ianb%40colorstudy.com > -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From mborch at gmail.com Tue Nov 24 22:28:31 2009 From: mborch at gmail.com (Malthe Borch) Date: Tue, 24 Nov 2009 22:28:31 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> Message-ID: <4B0C4FFF.5070305@gmail.com> On 11/24/09 6:44 PM, Ian Bicking wrote: > Have you read the threads on WSGI 2? These issues are discussed at > length, though they haven't been put into a spec. Okay, sounds good. I have tried to follow up on the discussion, but there's just too much noise to find out what the consensus is. > 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. 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. \malthe From mborch at gmail.com Tue Nov 24 22:28:31 2009 From: mborch at gmail.com (Malthe Borch) Date: Tue, 24 Nov 2009 22:28:31 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> Message-ID: <4B0C4FFF.5070305@gmail.com> On 11/24/09 6:44 PM, Ian Bicking wrote: > Have you read the threads on WSGI 2? These issues are discussed at > length, though they haven't been put into a spec. Okay, sounds good. I have tried to follow up on the discussion, but there's just too much noise to find out what the consensus is. > 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. 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. \malthe From ianb at colorstudy.com Tue Nov 24 22:35:11 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 24 Nov 2009 15:35:11 -0600 Subject: [Web-SIG] Future of WSGI In-Reply-To: <4B0C4FFF.5070305@gmail.com> References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> Message-ID: On Tue, Nov 24, 2009 at 3:28 PM, Malthe Borch 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mborch at gmail.com Tue Nov 24 22:40:03 2009 From: mborch at gmail.com (Malthe Borch) Date: Tue, 24 Nov 2009 22:40:03 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> Message-ID: 2009/11/24 Ian Bicking : > All the things that are specified to be str, would stay str in Python 3. Gotcha. > 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. \malthe From ianb at colorstudy.com Tue Nov 24 22:43:46 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 24 Nov 2009 15:43:46 -0600 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> Message-ID: On Tue, Nov 24, 2009 at 3:40 PM, Malthe Borch 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mborch at gmail.com Tue Nov 24 22:50:00 2009 From: mborch at gmail.com (Malthe Borch) Date: Tue, 24 Nov 2009 22:50:00 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> Message-ID: 2009/11/24 Ian Bicking : > 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. How people use or abuse software is not our concern; but the standard library should not itself abuse its own abstractions. The file-like (stream) interface is fine, but it must not live in the HTTP environment. I don't know of any other languages that mix the two (Perl's CGI.pm does, but that's another matter). Rather, what we need a request object. Don't think WebOb or ZPublisher. This is just a decoder for the socket response. It's quite symmetric: Request = namedtuple("Request", "environ body") Response = namedtuple("Response", "status headers iterable") Iterable might be "body" or "chunks" or some other term. \malthe From ianb at colorstudy.com Tue Nov 24 22:51:43 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 24 Nov 2009 15:51:43 -0600 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> Message-ID: On Tue, Nov 24, 2009 at 3:50 PM, Malthe Borch wrote: > 2009/11/24 Ian Bicking : > > 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. > > How people use or abuse software is not our concern; but the standard > library should not itself abuse its own abstractions. > > The file-like (stream) interface is fine, but it must not live in the > HTTP environment. I don't know of any other languages that mix the two > (Perl's CGI.pm does, but that's another matter). > Why does this matter? -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianb at colorstudy.com Tue Nov 24 23:30:20 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 24 Nov 2009 16:30:20 -0600 Subject: [Web-SIG] Future of WSGI In-Reply-To: <4B0C5B25.4080707@defuze.org> References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> <4B0C5B25.4080707@defuze.org> Message-ID: On Tue, Nov 24, 2009 at 4:16 PM, Sylvain Hellegouarch 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh at defuze.org Tue Nov 24 23:16:05 2009 From: sh at defuze.org (Sylvain Hellegouarch) Date: Tue, 24 Nov 2009 23:16:05 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> Message-ID: <4B0C5B25.4080707@defuze.org> > > 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... - Sylvain From henry at precheur.org Tue Nov 24 23:47:53 2009 From: henry at precheur.org (Henry Precheur) Date: Tue, 24 Nov 2009 14:47:53 -0800 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> <20091124222507.GA23879@banane.novuscom.net> Message-ID: <20091124224753.GA9478@banane.novuscom.net> On Tue, Nov 24, 2009 at 11:36:57PM +0100, Malthe Borch wrote: > 2009/11/24 Henry Precheur : > > (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 From mborch at gmail.com Tue Nov 24 23:57:08 2009 From: mborch at gmail.com (Malthe Borch) Date: Tue, 24 Nov 2009 23:57:08 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: <20091124224753.GA9478@banane.novuscom.net> References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> <20091124222507.GA23879@banane.novuscom.net> <20091124224753.GA9478@banane.novuscom.net> Message-ID: 2009/11/24 Henry Precheur : > 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 From henry at precheur.org Wed Nov 25 00:00:06 2009 From: henry at precheur.org (Henry Precheur) Date: Tue, 24 Nov 2009 15:00:06 -0800 Subject: [Web-SIG] Future of WSGI In-Reply-To: <4B0C5B25.4080707@defuze.org> References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> <4B0C5B25.4080707@defuze.org> Message-ID: <20091124230006.GA21743@banane.novuscom.net> 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 From henry at precheur.org Wed Nov 25 00:18:39 2009 From: henry at precheur.org (Henry Precheur) Date: Tue, 24 Nov 2009 15:18:39 -0800 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0C4FFF.5070305@gmail.com> <20091124222507.GA23879@banane.novuscom.net> <20091124224753.GA9478@banane.novuscom.net> Message-ID: <20091124231839.GA29755@banane.novuscom.net> On Tue, Nov 24, 2009 at 11:57:08PM +0100, Malthe Borch wrote: > 2009/11/24 Henry Precheur : > > Are you talking about PEP-333 or RFC 2616? > > RFC 2616, which you linked to. Environment is not an 'official' term in RFC 2616, because it's about HTTP, not WSGI. > > Then what? Your proposal doesn't work. So let's forget about it and > > stick to dict? > > class Request(object): > ... > > class Response(object): > ... 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". -- Henry Pr?cheur From mborch at gmail.com Wed Nov 25 00:29:08 2009 From: mborch at gmail.com (Malthe Borch) Date: Wed, 25 Nov 2009 00:29:08 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: <20091124231839.GA29755@banane.novuscom.net> References: <20091124222507.GA23879@banane.novuscom.net> <20091124224753.GA9478@banane.novuscom.net> <20091124231839.GA29755@banane.novuscom.net> Message-ID: 2009/11/25 Henry Precheur : > 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 From sh at defuze.org Wed Nov 25 08:51:22 2009 From: sh at defuze.org (Sylvain Hellegouarch) Date: Wed, 25 Nov 2009 08:51:22 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: <20091124230006.GA21743@banane.novuscom.net> References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> <4B0C5B25.4080707@defuze.org> <20091124230006.GA21743@banane.novuscom.net> Message-ID: <4B0CE1FA.7080308@defuze.org> Henry Precheur a ?crit : > 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? > If I'm not mistaken that's what people do when they want performances rather than portability. But point taken. > 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. > Well thank you for the reminder but I kind of knew that ;) It doesn't mean it's neither elegant nor efficient to create such a low level object. > >> (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. > > I talked about object creation not object passing. - Sylvain From sh at defuze.org Wed Nov 25 08:56:43 2009 From: sh at defuze.org (Sylvain Hellegouarch) Date: Wed, 25 Nov 2009 08:56:43 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: <20091124231839.GA29755@banane.novuscom.net> References: <4B0C4FFF.5070305@gmail.com> <20091124222507.GA23879@banane.novuscom.net> <20091124224753.GA9478@banane.novuscom.net> <20091124231839.GA29755@banane.novuscom.net> Message-ID: <4B0CE33B.3040904@defuze.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". > > 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 From sh at defuze.org Wed Nov 25 09:40:11 2009 From: sh at defuze.org (Sylvain Hellegouarch) Date: Wed, 25 Nov 2009 09:40:11 +0100 (CET) Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <20091124222507.GA23879@banane.novuscom.net> <20091124224753.GA9478@banane.novuscom.net> <20091124231839.GA29755@banane.novuscom.net> Message-ID: <52712.193.253.216.132.1259138411.squirrel@mail1.webfaction.com> > 2009/11/25 Henry Precheur : >> 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. > Personally, I would favor the idea that WSGI2 specifies the way headers should be mapped to object attributes (e.g. Content-Type would become content_type) and then let duck typing magic happen rather than specifying a class from which to inherit for instance. Instead of a dictionary, you'd provide an object that maps headers and a few other attributes accordingly. But again, it's just wishful thinking ;) - Sylvain -- Sylvain Hellegouarch http://www.defuze.org From chris.dent at gmail.com Wed Nov 25 12:42:15 2009 From: chris.dent at gmail.com (Chris Dent) Date: Wed, 25 Nov 2009 11:42:15 +0000 Subject: [Web-SIG] Future of WSGI In-Reply-To: <4B0C5B25.4080707@defuze.org> References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> <4B0C5B25.4080707@defuze.org> Message-ID: On Nov 24, 2009, at 10:16 PM, 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 (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... I use the raw dictionary in TiddlyWeb , and I like it that way. I've resisted using existing frameworks exactly because they _do_ package the WSGI stuff up in what I perceive to be complex classes that obscure the overall flexibility and transparency presented by the WSGI dict. I prefer middleware that just uses the dict that it gets, maybe making a few tweaks or additions and then passes it along to the next layer. This behavior is _exactly_ what makes WSGI great and useful. Beyond that I just have a knee jerk reaction to the creation of gratuitous classes for something that is essentially a (very flexible) data structure. I can (barely) relate to some of the complaints that start_response is a pain in the ass, but environ, to me, is not broken. On start_response, I find that I can mess with it (replacing it with something else, usually) before I go deeper into a stack of WSGI applications is sometimes useful, so I would be disappointed if I lost that option. From pje at telecommunity.com Wed Nov 25 16:41:24 2009 From: pje at telecommunity.com (P.J. Eby) Date: Wed, 25 Nov 2009 10:41:24 -0500 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> <4B0C5B25.4080707@defuze.org> Message-ID: <20091125154131.132D43A407F@sparrow.telecommunity.com> At 11:42 AM 11/25/2009 +0000, Chris Dent wrote: >On start_response, I find that I can mess with it (replacing it with >something else, usually) before I go deeper into a stack of WSGI >applications is sometimes useful, so I would be disappointed if I lost >that option. Note that in the WSGI 2 calling protocol, you would simply modify your return values, rather than needing to create a function and pass it down the call chain. From fumanchu at aminus.org Wed Nov 25 17:54:05 2009 From: fumanchu at aminus.org (Robert Brewer) Date: Wed, 25 Nov 2009 08:54:05 -0800 Subject: [Web-SIG] Future of WSGI In-Reply-To: <52712.193.253.216.132.1259138411.squirrel@mail1.webfaction.com> References: <20091124222507.GA23879@banane.novuscom.net><20091124224753.GA9478@banane.novuscom.net><20091124231839.GA29755@banane.novuscom.net> <52712.193.253.216.132.1259138411.squirrel@mail1.webfaction.com> Message-ID: Sylvain Hellegouarch wrote: > Personally, I would favor the idea that WSGI2 specifies the way headers > should be mapped to object attributes (e.g. Content-Type would become > content_type) and then let duck typing magic happen rather than > specifying a class from which to inherit for instance. How would you handle HTTP extension headers like X-MyEnterprise-Metadata? Cook [1] might be appropriate to read here: "...abstract data types facilitate adding new operations, while [objects] facilitate adding new representations... Abstract data types define operations that collect together the behaviors for a given action. Objects organize the matrix the other way, collecting together all the actions associated with a given representation. It is easier to add new operations in an ADT, and new representations using objects." IMO, it's quite appropriate that we essentially use an ADT (a dict) at the lowest level, precisely because it constrains the representation. This is the essence of The Zen of CherryPy #8 "Subclassed builtins are better than custom types" (really, custom _classes_) and #9 "But builtin types are even better". People can then objectify those ADTs to their representational taste. Robert Brewer fumanchu at aminus.org [1] http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf [2] http://www.cherrypy.org/wiki/ZenOfCherryPy#a8.Subclassedbuiltinsarebette rthancustomtypes. From sh at defuze.org Wed Nov 25 18:30:18 2009 From: sh at defuze.org (Sylvain Hellegouarch) Date: Wed, 25 Nov 2009 18:30:18 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <20091124222507.GA23879@banane.novuscom.net><20091124224753.GA9478@banane.novuscom.net><20091124231839.GA29755@banane.novuscom.net> <52712.193.253.216.132.1259138411.squirrel@mail1.webfaction.com> Message-ID: <4B0D69AA.5050108@defuze.org> Robert Brewer a ?crit : > Sylvain Hellegouarch wrote: > >> Personally, I would favor the idea that WSGI2 specifies the way >> > headers > >> should be mapped to object attributes (e.g. Content-Type would become >> content_type) and then let duck typing magic happen rather than >> specifying a class from which to inherit for instance. >> > > How would you handle HTTP extension headers like > X-MyEnterprise-Metadata? > x_myenteprise_metadata Now I get this only makes sense where the header is valid as a Python identifier so more limited than a dict key for sure. > Cook [1] might be appropriate to read here: "...abstract data types > facilitate adding new operations, while [objects] facilitate adding new > representations... Abstract data types define operations that collect > together the behaviors for a given action. Objects organize the matrix > the other way, collecting together all the actions associated with a > given representation. It is easier to add new operations in an ADT, and > new representations using objects." > But that's my point, we discuss request representation, not behavior. > IMO, it's quite appropriate that we essentially use an ADT (a dict) at > the lowest level, precisely because it constrains the representation. > This is the essence of The Zen of CherryPy #8 "Subclassed builtins are > better than custom types" (really, custom _classes_) and #9 "But builtin > types are even better". People can then objectify those ADTs to their > representational taste. > That's fine but looks redundant eventually in my opinion. - Sylvain From arw1961 at yahoo.com Wed Nov 25 20:50:22 2009 From: arw1961 at yahoo.com (Aaron Watters) Date: Wed, 25 Nov 2009 11:50:22 -0800 (PST) Subject: [Web-SIG] Future of WSGI In-Reply-To: Message-ID: <246963.58441.qm@web32001.mail.mud.yahoo.com> --- On Wed, 11/25/09, Chris Dent wrote: > From: Chris Dent > I can (barely) relate to some of the complaints that > start_response is a pain in the ass, but environ, to me, is > not broken. I agree. It maps nicely onto the underlying protocol and WSGI is supposed to be low level right? The biggest problem with start_response is that after you evaluate iterable = application(env, start_response) Sometimes the start_response has been called and sometimes it hasn't, and this can break middlewares when they haven't been tested both ways (repose.who for example seems to assume it has been called). By the way, I created a little interface for archiving notes about wsgi2 here http://listtree.appspot.com/wsgi2 To add to it you need to fill in a captcha and use the password "wsgi". I thought I announced this to web-sig yesterday, but apparently I messed up my reply-to. If you like, please add something there. I'd be delighted if you did. I think it might be an interface that is easier to "scan" than a million emails. -- Aaron Watters From mborch at gmail.com Wed Nov 25 21:00:58 2009 From: mborch at gmail.com (Malthe Borch) Date: Wed, 25 Nov 2009 21:00:58 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: <246963.58441.qm@web32001.mail.mud.yahoo.com> References: <246963.58441.qm@web32001.mail.mud.yahoo.com> Message-ID: 2009/11/25 Aaron Watters : >> From: Chris Dent >> I can (barely) relate to some of the complaints that >> start_response is a pain in the ass, but environ, to me, is >> not broken. > > I agree. ?It maps nicely onto the underlying protocol > and WSGI is supposed to be low level right? It's not ``environ`` which is broken, it is the "special" entries like wsgi.input and wsgi.multithread. That's because I equate ``environ`` with the request headers. It may be wrong. But if ``environ`` reflects the entire request and not just the headers, why is it then not called ``request``. Can we really talk about the request stream as the "environment" in which the request must be answered? Or is it in fact, the "payload". \malthe From tseaver at palladion.com Wed Nov 25 21:03:26 2009 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 25 Nov 2009 15:03:26 -0500 Subject: [Web-SIG] Future of WSGI In-Reply-To: <246963.58441.qm@web32001.mail.mud.yahoo.com> References: <246963.58441.qm@web32001.mail.mud.yahoo.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Watters wrote: > > --- On Wed, 11/25/09, Chris Dent wrote: > >> From: Chris Dent >> I can (barely) relate to some of the complaints that >> start_response is a pain in the ass, but environ, to me, is >> not broken. > > I agree. It maps nicely onto the underlying protocol > and WSGI is supposed to be low level right? > > The biggest problem with start_response is that after > you evaluate > > iterable = application(env, start_response) > > Sometimes the start_response has been called and sometimes > it hasn't, and this can break middlewares when they haven't > been tested both ways (repose.who for example seems to > assume it has been called). Since version 1.0.13 (2009-04-24), repoze.who's middleware is very careful to dance around the fact that an application is not required to have called 'start_response' on return, but *must* call it before returning the first chunk from its iterator. That bit of flexibility in PEP 333 is likely there to support *some* use case, but it makes 'start_response' a *big* pain to work with in middleware which needs to to "egress" processing of headers. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksNjYkACgkQ+gerLs4ltQ6M4ACgj8Ist6sCLUgJ/BrAlXP0QlN4 OEMAnjuWY0NEK+3IKc8igdaJx0wrlNqy =ncqc -----END PGP SIGNATURE----- From tseaver at palladion.com Wed Nov 25 21:08:40 2009 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 25 Nov 2009 15:08:40 -0500 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <246963.58441.qm@web32001.mail.mud.yahoo.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Malthe Borch wrote: > 2009/11/25 Aaron Watters : >>> From: Chris Dent >>> I can (barely) relate to some of the complaints that >>> start_response is a pain in the ass, but environ, to me, is >>> not broken. >> I agree. It maps nicely onto the underlying protocol >> and WSGI is supposed to be low level right? > > It's not ``environ`` which is broken, it is the "special" entries like > wsgi.input and wsgi.multithread. How about 'PATH_INFO', 'SCRIPT_NAME', etc: none of those are headers. Please re-read PEP 333[1] for the rationale. > That's because I equate ``environ`` with the request headers. It may > be wrong. You are: the environ is modeled on the CGI environment, which has lots more stuff in it than headers. > But if ``environ`` reflects the entire request and not just > the headers, why is it then not called ``request``. Because it is a dictionary like the one passed to CGI applications, ot a "request object". The looseness of a dict is part of why WSGI works for interoperability. [1] http://www.python.org/dev/peps/pep-0333/#id17 Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksNjscACgkQ+gerLs4ltQ5SXQCfQeRgnX6OUL+2d3vU7LQmqRoK fS0AoK+fPxXi9BYEqQw+UI9y7/OK3trV =mHsV -----END PGP SIGNATURE----- From ianb at colorstudy.com Wed Nov 25 21:48:30 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 25 Nov 2009 14:48:30 -0600 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <246963.58441.qm@web32001.mail.mud.yahoo.com> Message-ID: On Wed, Nov 25, 2009 at 2:03 PM, Tres Seaver wrote: > Aaron Watters wrote: > > > > --- On Wed, 11/25/09, Chris Dent wrote: > > > >> From: Chris Dent > >> I can (barely) relate to some of the complaints that > >> start_response is a pain in the ass, but environ, to me, is > >> not broken. > > > > I agree. It maps nicely onto the underlying protocol > > and WSGI is supposed to be low level right? > > > > The biggest problem with start_response is that after > > you evaluate > > > > iterable = application(env, start_response) > > > > Sometimes the start_response has been called and sometimes > > it hasn't, and this can break middlewares when they haven't > > been tested both ways (repose.who for example seems to > > assume it has been called). > > Since version 1.0.13 (2009-04-24), repoze.who's middleware is very > careful to dance around the fact that an application is not required to > have called 'start_response' on return, but *must* call it before > returning the first chunk from its iterator. That bit of flexibility in > PEP 333 is likely there to support *some* use case, but it makes > 'start_response' a *big* pain to work with in middleware which needs to > to "egress" processing of headers. > Just in terms of history, I think I'm to blame on this one, as I argued quite vigorously for start_response. The reason being that at the time frameworks that had a concept of "streaming" usually did it by writing to the response. While the names were different depending on the framework, this was the common way to do streaming: def file_app(req): filename = ... req.response.setHeader('Content-Type', mimetypes.guess_type(os.path.splitext(filename)[1])[0]) # I believe most did not stream by default... req.response.stream() fp = open(filename, 'rb') while 1: chunk = fp.read(4096) if not chunk: break req.response.write(chunk) To support that style of streaming start_response was added. I think PJE also had some notion of Comet-style interactions, and maybe something related to async, leading to the specific restrictions on how written content should be handled. I still don't entirely understand the use case underlying that. But anyway, that's some of the motivation. start_response is still useful for retrofitting support for frameworks from time to time, but all the modern frameworks work differently these days making start_response seem less necessary. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From and-py at doxdesk.com Thu Nov 26 14:06:32 2009 From: and-py at doxdesk.com (And Clover) Date: Thu, 26 Nov 2009 14:06:32 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> Message-ID: <4B0E7D58.4060102@doxdesk.com> Ian Bicking 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. Ah, OK, if that's where we got to I'm happy with that - as long as the application/framework can tell the difference between (a) old-school WSGI 1.0 decoded PATH_INFO, (b) new verbatim PATH_INFO, and (c) a new verbatim PATH_INFO that has been created from an old PATH_INFO by a WSGI handler unfortunate enough to be running under CGI or IIS, potentially including mangled characters. I would prefer to avoid the latter completely. This could be achieved by giving the new variables a different name and only including them if they're safe (leaving the application to fall back to the old variables where unavailable), or by having a flag to specify they're verbatim and leaving it unset when unmangled verbatim is unavailable. > Also I think everyone is okay with removing start_response. +0.5: very much happy to see it gone, but if it causes any more delay to a WSGI update I'm also not unhappy if it stays. My primary concern is that a Python-3-compatible WSGI is available as soon as possible; every long argument in here seems to lead to no resolution. I want to release Python 3 web code, and cannot whilst WSGI remains in flux. Whilst in principle I kind of agree with Malthe that keeping the CGI-derived environ separate from items like wsgi.input would be appropriate, in practice I don't give a stuff about it: the merged dictionary causes no practical problems, and changing it would be an enormous upheaval for all WSGI users. WSGI doesn't need to be pretty, it needs to be widely-compatible. Authors who want pretty can use frameworks, which will be happy to deliver elegant Request and Response objects. -- And Clover mailto:and at doxdesk.com http://www.doxdesk.com/ From mborch at gmail.com Thu Nov 26 15:54:51 2009 From: mborch at gmail.com (Malthe Borch) Date: Thu, 26 Nov 2009 15:54:51 +0100 Subject: [Web-SIG] Future of WSGI In-Reply-To: <4B0E7D58.4060102@doxdesk.com> References: <4B0BA030.5010201@gmail.com> <4B0E7D58.4060102@doxdesk.com> Message-ID: 2009/11/26 And Clover : > Whilst in principle I kind of agree with Malthe that keeping the CGI-derived > environ separate from items like wsgi.input would be appropriate, in > practice I don't give a stuff about it: the merged dictionary causes no > practical problems, and changing it would be an enormous upheaval for all > WSGI users. It will anyway (moving to Python 3). > WSGI doesn't need to be pretty, it needs to be widely-compatible. Authors > who want pretty can use frameworks, which will be happy to deliver elegant > Request and Response objects. It's not about pretty more than PEP 8 is about pretty (hint: it's not). \malthe From chrism at plope.com Thu Nov 26 19:02:04 2009 From: chrism at plope.com (Chris McDonough) Date: Thu, 26 Nov 2009 13:02:04 -0500 Subject: [Web-SIG] http://wiki.python.org/moin/WebFrameworks Message-ID: <4B0EC29C.6070300@plope.com> http://wiki.python.org/moin/WebFrameworks seems to be the place where folks are registering their respective web frameworks. I'd like to move some of the frameworks which are currently in the various categories which haven't been active in a few years. In particular, I'd like to move any framework which hasn't had a release since the beginning of 2008 (arbitrary) into the "Discontinued / Inactive" framework category. I'd be willing to do the work to make sure I wasn't moving one that actually *did* have releases past that but just hadn't updated the page. Any dissent? - C From graham.dumpleton at gmail.com Thu Nov 26 22:59:50 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Fri, 27 Nov 2009 08:59:50 +1100 Subject: [Web-SIG] Future of WSGI In-Reply-To: <4B0E7D58.4060102@doxdesk.com> References: <4B0BA030.5010201@gmail.com> <4B0E7D58.4060102@doxdesk.com> Message-ID: <88e286470911261359wee13680y3b7c807246235392@mail.gmail.com> 2009/11/27 And Clover : > Ian Bicking 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. > > Ah, OK, if that's where we got to I'm happy with that - as long as the > application/framework can tell the difference between (a) old-school WSGI > 1.0 decoded PATH_INFO, (b) new verbatim PATH_INFO, and (c) a new verbatim > PATH_INFO that has been created from an old PATH_INFO by a WSGI handler > unfortunate enough to be running under CGI or IIS, potentially including > mangled characters. I would prefer to avoid the latter completely. I was determined to stay out of this conversation, as don't particularly care anymore, but want to set the record straight. What Ian was describing was just one of a few proposals which were put up about additional changes to WSGI on top of what is already the defacto WSGI 1.X definition for Python 3.X as defined by existing practice in the form of wsgiref in Python 3.1 and mod_wsgi 3.0 (as implemented for more than a year, and recently released officially due to being fed up with waiting). One of the other major WSGI servers also is implementing that defacto WSGI 1.X definition for Python 3.X. That WSGI server hasn't as far as I know been officially released, so will leave it up to author to comment on whether they are still intending it to release it that way. Anyway, Ian's proposal just so happened to be the last one which was discussed. Just like the other proposals there were issues with it and not everyone necessarily agreed. Note that lack of response doesn't mean consent, and frankly various people were quite tired of the discussion at that point and various people whose opinions would be important to know had dropped out of the discussion. I would be even further disappointed in Python WEB-SIG if that last proposal now simply got rubber stamped purely because it was the last proposal anyone remembered, without some critical study done on whether it is even practical to implement in a reliable way across hosting mechanisms which don't have direct access to the actual processing of request headers and in particular the decoding of the original REQUEST_URI into SCRIPT_NAME and PATH_INFO. Specifically, in relation to the inability or potential difficulty in such hosting mechanisms to extract out from REQUEST_URI the original parts which mapped to the final SCRIPT_NAME and PATH_INFO. No matter what you all end up deciding to do, and whether or not start_response() is dropped, any new specification will have to be called WSGI 2.0 due to the existence of the defacto WSGI 1.X definition for Python 3.X. Graham From foom at fuhm.net Fri Nov 27 02:42:40 2009 From: foom at fuhm.net (James Y Knight) Date: Thu, 26 Nov 2009 20:42:40 -0500 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec Message-ID: I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the official definition of WSGI 1.1, which describes how to implement WSGI adapters for both Python 2.x and 3.x. It may not be perfect, but, it's been implemented twice, and seems ot have no fatal flaws (it doesn't do any lossy transforms, so any issues are irritations at worst). The basis for this definition is also described in the "WSGI 1.0 Ammendments" [2] page. The definitions as they stand are clear enough to understand and implement, but not currently in spec-worthy language. (e.g. it says "should" and "may" in a colloquial fashion, but actually means MUST in some places and SHOULD in others, as defined by RFC 2119) Thus, I'd like to suggest that Graham (if he's willing?) should reformat the "Definition"/"Ammendments" as an actual diff against the current PEP 333. Then, I will recommend adopting that document as an actual standard WSGI 1.1, to replace PEP 333. This discussion has gone on long enough, and it doesn't really matter as much to have the perfect API, as it does to have a standard. James [1] http://code.google.com/p/modwsgi/wiki/SupportForPython3X [2] http://www.wsgi.org/wsgi/Amendments_1.0 From pje at telecommunity.com Fri Nov 27 02:48:06 2009 From: pje at telecommunity.com (P.J. Eby) Date: Thu, 26 Nov 2009 20:48:06 -0500 Subject: [Web-SIG] Future of WSGI In-Reply-To: <88e286470911261359wee13680y3b7c807246235392@mail.gmail.com > References: <4B0BA030.5010201@gmail.com> <4B0E7D58.4060102@doxdesk.com> <88e286470911261359wee13680y3b7c807246235392@mail.gmail.com> Message-ID: <20091127014814.DD9483A40A2@sparrow.telecommunity.com> At 08:59 AM 11/27/2009 +1100, Graham Dumpleton wrote: >Just like the other proposals there were issues with it and >not everyone necessarily agreed. True, but it also (mostly) reflected the discussions prior to that point, striking me as a fairly good compromise. I wasn't totally keen on the special URI handling, but was willing to accept it in order to just get something done. While it might be meaningful to have some critical study on the URI handling, there is also the issue that this might sit around for another year or two with no action. Sometimes, the time when everyone is tired of arguing is *precisely* the time to push forward and actually get something done. ;-) From arw1961 at yahoo.com Fri Nov 27 15:47:49 2009 From: arw1961 at yahoo.com (Aaron Watters) Date: Fri, 27 Nov 2009 06:47:49 -0800 (PST) Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: Message-ID: <517344.29682.qm@web32005.mail.mud.yahoo.com> I second the move, recorded here: http://listtree.appspot.com/wsgi2/ICvaujouPxb2gfEhDS_aiw -- Aaron Watters --- On Thu, 11/26/09, James Y Knight wrote: > From: James Y Knight > Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec > To: "Web SIG" > Date: Thursday, November 26, 2009, 8:42 PM > I move to bless mod_wsgi's definition > of WSGI 1.1 [1] as the official definition of WSGI 1.1, > which describes how to implement WSGI adapters for both > Python 2.x and 3.x. It may not be perfect, but, it's been > implemented twice, and seems ot have no fatal flaws (it > doesn't do any lossy transforms, so any issues are > irritations at worst). The basis for this definition is also > described in the "WSGI 1.0 Ammendments" [2] page. > > The definitions as they stand are clear enough to > understand and implement, but not currently in spec-worthy > language. (e.g. it says "should" and "may" in a colloquial > fashion, but actually means MUST in some places and SHOULD > in others, as defined by RFC 2119) > > Thus, I'd like to suggest that Graham (if he's willing?) > should reformat the "Definition"/"Ammendments" as an actual > diff against the current PEP 333. Then, I will recommend > adopting that document as an actual standard WSGI 1.1, to > replace PEP 333. > > This discussion has gone on long enough, and it doesn't > really matter as much to have the perfect API, as it does to > have a standard. > > James > > [1] http://code.google.com/p/modwsgi/wiki/SupportForPython3X > [2] http://www.wsgi.org/wsgi/Amendments_1.0 > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/arw1961%40yahoo.com > From pje at telecommunity.com Fri Nov 27 16:20:48 2009 From: pje at telecommunity.com (P.J. Eby) Date: Fri, 27 Nov 2009 10:20:48 -0500 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: References: Message-ID: <20091127152058.AE9A43A40A8@sparrow.telecommunity.com> At 08:42 PM 11/26/2009 -0500, James Y Knight wrote: >I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the >official definition of WSGI 1.1, which describes how to implement >WSGI adapters for both Python 2.x and 3.x. It may not be perfect, >but, it's been implemented twice, and seems ot have no fatal flaws >(it doesn't do any lossy transforms, so any issues are irritations >at worst). The basis for this definition is also described in the >"WSGI 1.0 Ammendments" [2] page. > >The definitions as they stand are clear enough to understand and >implement, but not currently in spec-worthy language. (e.g. it says >"should" and "may" in a colloquial fashion, but actually means MUST >in some places and SHOULD in others, as defined by RFC 2119) > >Thus, I'd like to suggest that Graham (if he's willing?) should >reformat the "Definition"/"Ammendments" as an actual diff against >the current PEP 333. Then, I will recommend adopting that document >as an actual standard WSGI 1.1, to replace PEP 333. I'm +1, with a few caveats. First, as you mention, it needs to be spec'd properly. In particular, it should be clarified that the main changes are to *allow byte strings* in certain places where WSGI 1.0 demands a unicode string w/latin-1 encoding. Second, I do not think that the "additional guarantees/requirements" can be safely added to a 1.x version, as they make it impossible for an app to tell whether it's *really* running under 1.1 or under a broken piece of middleware that's passing through wsgi.version but not actually providing 1.1-level guarantees. I would therefore suggest that these additional guarantees and requirements be deferred to WSGI 2.0. From foom at fuhm.net Fri Nov 27 18:34:22 2009 From: foom at fuhm.net (James Y Knight) Date: Fri, 27 Nov 2009 12:34:22 -0500 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: <20091127152058.AE9A43A40A8@sparrow.telecommunity.com> References: <20091127152058.AE9A43A40A8@sparrow.telecommunity.com> Message-ID: <3CD63F68-4922-4B37-A3DA-85713825AC33@fuhm.net> On Nov 27, 2009, at 10:20 AM, P.J. Eby wrote: > Second, I do not think that the "additional guarantees/requirements" can be safely added to a 1.x version, as they make it impossible for an app to tell whether it's *really* running under 1.1 or under a broken piece of middleware that's passing through wsgi.version but not actually providing 1.1-level guarantees. I would therefore suggest that these additional guarantees and requirements be deferred to WSGI 2.0. Okay, let's look at these additional requirements in more detail. I see 4 that should be kept, 1 that can be dispensed with, and 1 I'm not sure about. > 1. The 'readline()' function of 'wsgi.input' may optionally take a size hint. Already de-facto required. Leaving it out helps no-one. KEEP. > 2. The 'wsgi.input' must provide an empty string as end of input stream marker. I don't think this will be a problem. What would WSGI middleware do to break this requirement? It was only put in in the first place so that CGI adapters could pass through their input stream (which may not ever provide an EOF) without having to wrap it. I agree that was a mistake, and should be corrected. KEEP. > 3. The size argument to 'read()' function of 'wsgi.input' would be optional and if not supplied the function would return all available request content. Thus would make 'wsgi.input' more file like as the WSGI specification suggests it is, but isn't really per original definition. This one could be a problem with middleware, and that feature shouldn't ever be used, in any case: reading into memory an arbitrary amount of data from a client is not a good thing to encourage. OMIT. > 4. The 'wsgi.file_wrapper' supplied by the WSGI adapter must honour the Content-Length response header and must only return from the file that amount of content. This would guarantee that using wsgi.file_wrapper to return part of a file for byte range requests would work. Given item #6, I suppose this is actually just a matter of efficiency, in case the file wrapper is sent to a middleware rather than directly to the wsgi gateway? If it goes directly to the gateway, that can of course stop reading by itself. ?undecided? > 5. Any WSGI application or middleware should not return more data than specified by the Content-Length response header if defined. As long as this is meant as "SHOULD", that's fine. It's not actually a requirement, but rather a suggestion of best practices. KEEP. > 6. The WSGI adapter must not pass on to the server any data above what the Content-Length response header defines if supplied. This is already required by HTTP. If the WSGI gateway doesn't make this happen somehow, it's generating invalid HTTP and that's a bug. Okay to clarify in the spec to ensure people don't miss the requirement when implementing. KEEP. James From pje at telecommunity.com Fri Nov 27 19:20:44 2009 From: pje at telecommunity.com (P.J. Eby) Date: Fri, 27 Nov 2009 13:20:44 -0500 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: <3CD63F68-4922-4B37-A3DA-85713825AC33@fuhm.net> References: <20091127152058.AE9A43A40A8@sparrow.telecommunity.com> <3CD63F68-4922-4B37-A3DA-85713825AC33@fuhm.net> Message-ID: <20091127182053.A6ACC3A40A8@sparrow.telecommunity.com> At 12:34 PM 11/27/2009 -0500, James Y Knight wrote: >On Nov 27, 2009, at 10:20 AM, P.J. Eby wrote: > > Second, I do not think that the "additional > guarantees/requirements" can be safely added to a 1.x version, as > they make it impossible for an app to tell whether it's *really* > running under 1.1 or under a broken piece of middleware that's > passing through wsgi.version but not actually providing 1.1-level > guarantees. I would therefore suggest that these additional > guarantees and requirements be deferred to WSGI 2.0. > >Okay, let's look at these additional requirements in more detail. I >see 4 that should be kept, 1 that can be dispensed with, and 1 I'm >not sure about. I agree with 2 of your keeps, and remain -0.5 to -1 on the others. See below... > > 1. The 'readline()' function of 'wsgi.input' may optionally take > a size hint. > >Already de-facto required. Leaving it out helps no-one. KEEP. Fair enough, since it's a MAY. On the other hand, because it's a MAY, it actually *helps* no-one, from a spec compatibility POV. (That is, you have to test whether it's available, so it's no different than it not being in the spec to begin with.) So, putting it in doesn't *hurt*, but neither does it *help*... so I lean towards leaving it to 2.x, where it can actually help. > > 2. The 'wsgi.input' must provide an empty string as end of input > stream marker. > >I don't think this will be a problem. What would WSGI middleware do >to break this requirement? It could be reading the original input stream, and replacing it with another one. Not very common I would guess, but it's still possible for a piece of perfectly valid 1.0 middleware to fail this requirement for 1.1, leading to the condition where you really can't tell if you're running valid 1.1 or not. >It was only put in in the first place so that CGI adapters could >pass through their input stream (which may not ever provide an EOF) >without having to wrap it. I agree that was a mistake, and should be >corrected. I agree... but only in 2.x. > > 3. The size argument to 'read()' function of 'wsgi.input' would > be optional and if not supplied the function would return all > available request content. Thus would make 'wsgi.input' more file > like as the WSGI specification suggests it is, but isn't really per > original definition. > >This one could be a problem with middleware, and that feature >shouldn't ever be used, in any case: reading into memory an >arbitrary amount of data from a client is not a good thing to encourage. OMIT. Agreed -- even in 2.x it's questionable if not harmful. > > 4. The 'wsgi.file_wrapper' supplied by the WSGI adapter must > honour the Content-Length response header and must only return from > the file that amount of content. This would guarantee that using > wsgi.file_wrapper to return part of a file for byte range requests would work. > >Given item #6, I suppose this is actually just a matter of >efficiency, in case the file wrapper is sent to a middleware rather >than directly to the wsgi gateway? If it goes directly to the >gateway, that can of course stop reading by itself. ?undecided? I don't really see how this one helps anything in 1.x, and so lean towards leaving it out. > > 5. Any WSGI application or middleware should not return more data > than specified by the Content-Length response header if defined. > >As long as this is meant as "SHOULD", that's fine. It's not actually >a requirement, but rather a suggestion of best practices. KEEP. > > > 6. The WSGI adapter must not pass on to the server any data above > what the Content-Length response header defines if supplied. > >This is already required by HTTP. If the WSGI gateway doesn't make >this happen somehow, it's generating invalid HTTP and that's a bug. >Okay to clarify in the spec to ensure people don't miss the >requirement when implementing. KEEP. Good points - I agree with these two, and they can be considered 1.0 clarifications as well. After the first four (which I see no reason to include) I was probably a little over-inclined to throw these two out (especially since I was reading the "should" above as a "must", per your proposal). From ianb at colorstudy.com Fri Nov 27 21:03:48 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 27 Nov 2009 14:03:48 -0600 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: <20091127182053.A6ACC3A40A8@sparrow.telecommunity.com> References: <20091127152058.AE9A43A40A8@sparrow.telecommunity.com> <3CD63F68-4922-4B37-A3DA-85713825AC33@fuhm.net> <20091127182053.A6ACC3A40A8@sparrow.telecommunity.com> Message-ID: On Fri, Nov 27, 2009 at 12:20 PM, P.J. Eby wrote: > >> > 1. The 'readline()' function of 'wsgi.input' may optionally take a size >> hint. >> >> Already de-facto required. Leaving it out helps no-one. KEEP. >> > > Fair enough, since it's a MAY. On the other hand, because it's a MAY, it > actually *helps* no-one, from a spec compatibility POV. (That is, you have > to test whether it's available, so it's no different than it not being in > the spec to begin with.) > > So, putting it in doesn't *hurt*, but neither does it *help*... so I lean > towards leaving it to 2.x, where it can actually help. I think it was meant to be a must. The *caller* MAY pass in a size hint, the implementor MUST implement this optional argument. This is the de-facto requirement. > > 2. The 'wsgi.input' must provide an empty string as end of input stream >> marker. >> >> I don't think this will be a problem. What would WSGI middleware do to >> break this requirement? >> > > It could be reading the original input stream, and replacing it with > another one. Not very common I would guess, but it's still possible for a > piece of perfectly valid 1.0 middleware to fail this requirement for 1.1, > leading to the condition where you really can't tell if you're running valid > 1.1 or not. Middleware sometimes does this, but any time it does this it always replaces the input stream with something truly file-like, e.g., StringIO or a temp file. Nothing but servers really hands sockets around, and sockets are the only objects I'm aware of that don't act quite like a file. It was only put in in the first place so that CGI adapters could pass >> through their input stream (which may not ever provide an EOF) without >> having to wrap it. I agree that was a mistake, and should be corrected. >> > > I agree... but only in 2.x. > > > > > 3. The size argument to 'read()' function of 'wsgi.input' would be >> optional and if not supplied the function would return all available request >> content. Thus would make 'wsgi.input' more file like as the WSGI >> specification suggests it is, but isn't really per original definition. >> >> This one could be a problem with middleware, and that feature shouldn't >> ever be used, in any case: reading into memory an arbitrary amount of data >> from a client is not a good thing to encourage. OMIT. >> > > Agreed -- even in 2.x it's questionable if not harmful. Well, we need a way to handle content of unknown length, but if the file terminates with '' then this isn't that important. > 4. The 'wsgi.file_wrapper' supplied by the WSGI adapter must honour the >> Content-Length response header and must only return from the file that >> amount of content. This would guarantee that using wsgi.file_wrapper to >> return part of a file for byte range requests would work. >> >> Given item #6, I suppose this is actually just a matter of efficiency, in >> case the file wrapper is sent to a middleware rather than directly to the >> wsgi gateway? If it goes directly to the gateway, that can of course stop >> reading by itself. ?undecided? >> > > I don't really see how this one helps anything in 1.x, and so lean towards > leaving it out. I don't really understand this either, unless it was handling range responses as well. Content-Length alone isn't very interesting in this case. > 5. Any WSGI application or middleware should not return more data than >> specified by the Content-Length response header if defined. >> >> As long as this is meant as "SHOULD", that's fine. It's not actually a >> requirement, but rather a suggestion of best practices. KEEP. >> >> > 6. The WSGI adapter must not pass on to the server any data above what >> the Content-Length response header defines if supplied. >> >> This is already required by HTTP. If the WSGI gateway doesn't make this >> happen somehow, it's generating invalid HTTP and that's a bug. Okay to >> clarify in the spec to ensure people don't miss the requirement when >> implementing. KEEP. >> > > Good points - I agree with these two, and they can be considered 1.0 > clarifications as well. After the first four (which I see no reason to > include) I was probably a little over-inclined to throw these two out > (especially since I was reading the "should" above as a "must", per your > proposal). In this context, maybe 4 is just an extension of these? Put 4 after 6 and maybe it'll seem more obvious...? -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Fri Nov 27 22:27:50 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Sat, 28 Nov 2009 08:27:50 +1100 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: References: Message-ID: <88e286470911271327p24dc978at5ee46e3ad1c99220@mail.gmail.com> Please ensure you have also all read: http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html I will post again later in detail when have some time to explain a few more points not mentioned in that post and where people aren't quite understanding the reasoning for doing things. One very quick comment about read(). Allowing read() with no argument is no different to a user saying read(environ['CONTENT_LENGTH']). Because a WSGI adapter/middleware is going to have to track bytes read to ensure can return an empty string as end sentinel, it will know length remaining and would internally for read() with no argument do read(remaining_bytes). As such no real differences in inefficiencies as far as memory use goes for implementing read() because of need to implement end sentinel. Also, you have concerns about read() with no argument, but frankly readline() with no argument, which is already required, is much worse because you cant really track bytes read and just read to end of input. This is because they only want to read to end of line and so reading all input is going to blow out memory use unreasonably as you speculate for read(). As such, a readline() implementation is likely to read in blocks and internally buffer where read() doesn't necessarily have to. It may also be pertinent to read: http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html as from memory it talks about issues with not paying attention to Content-Length on output filtering middleware as well. As I said, will reply later when have some time to focus. Right now I have a 2 year old to keep amused. Graham 2009/11/27 James Y Knight : > I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the official definition of WSGI 1.1, which describes how to implement WSGI adapters for both Python 2.x and 3.x. It may not be perfect, but, it's been implemented twice, and seems ot have no fatal flaws (it doesn't do any lossy transforms, so any issues are irritations at worst). The basis for this definition is also described in the "WSGI 1.0 Ammendments" [2] page. > > The definitions as they stand are clear enough to understand and implement, but not currently in spec-worthy language. (e.g. it says "should" and "may" in a colloquial fashion, but actually means MUST in some places and SHOULD in others, as defined by RFC 2119) > > Thus, I'd like to suggest that Graham (if he's willing?) should reformat the "Definition"/"Ammendments" as an actual diff against the current PEP 333. Then, I will recommend adopting that document as an actual standard WSGI 1.1, to replace PEP 333. > > This discussion has gone on long enough, and it doesn't really matter as much to have the perfect API, as it does to have a standard. > > James > > [1] http://code.google.com/p/modwsgi/wiki/SupportForPython3X > [2] http://www.wsgi.org/wsgi/Amendments_1.0 > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com > From mark.mchristensen at gmail.com Sat Nov 28 05:52:21 2009 From: mark.mchristensen at gmail.com (Mark Ramm) Date: Fri, 27 Nov 2009 23:52:21 -0500 Subject: [Web-SIG] http://wiki.python.org/moin/WebFrameworks In-Reply-To: <4B0EC29C.6070300@plope.com> References: <4B0EC29C.6070300@plope.com> Message-ID: No dissent here. I think that page should be kept as up to date and relevant as possible, because we do have a diverse set of web tools, which can make it hard to choose, so having some summary is a very good thing. I also think that diversity is one of the most important signs of a healthy ecosystem, so we should celebrate it, in spite of some of the "one framework to rule them all" crowd. --Mark Ramm On Thu, Nov 26, 2009 at 1:02 PM, Chris McDonough wrote: > http://wiki.python.org/moin/WebFrameworks seems to be the place where folks > are registering their respective web frameworks. > > I'd like to move some of the frameworks which are currently in the various > categories which haven't been active in a few years. ?In particular, I'd > like to move any framework which hasn't had a release since the beginning of > 2008 (arbitrary) into the "Discontinued / Inactive" framework category. ?I'd > be willing to do the work to make sure I wasn't moving one that actually > *did* have releases past that but just hadn't updated the page. > > Any dissent? > > - C > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/mark.mchristensen%40gmail.com > -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog From arw1961 at yahoo.com Sat Nov 28 19:03:40 2009 From: arw1961 at yahoo.com (Aaron Watters) Date: Sat, 28 Nov 2009 10:03:40 -0800 (PST) Subject: [Web-SIG] http://wiki.python.org/moin/WebFrameworks In-Reply-To: Message-ID: <40498.81048.qm@web32001.mail.mud.yahoo.com> > > On Thu, Nov 26, 2009 at 1:02 PM, Chris McDonough > wrote: > > http://wiki.python.org/moin/WebFrameworks > seems to be the place where folks > > are registering their respective web frameworks. > > > > I'd like to move some of the frameworks which are > currently in the various > > categories which haven't been active in a few years. > ?In particular, I'd > > like to move any framework which hasn't had a release > since the beginning of > > 2008 (arbitrary) into the "Discontinued / Inactive" > framework category. ?I'd > > be willing to do the work to make sure I wasn't moving > one that actually > > *did* have releases past that but just hadn't updated > the page. > > > > Any dissent? > > > > - C Why not call them "apparently stable" versus "under active development"? Is the cgi module "discontinued"? I'm a little sensitive on this topic because people tell me that Gadfly is "inactive" or "discontinued" but it still does what it does as documented very well. Frequent releases may actually be a sign of bugginess and bad design. If you suspect a project is really dead, maybe you could try to contact the authors and ask about what they think. -- Aaron Watters === BTW, I think "Release early, release often" is nonsense because it means you are probably releasing something buggy and unstable which will just alienate your users, who will never come back to see the better version. From chrism at plope.com Sat Nov 28 21:03:35 2009 From: chrism at plope.com (Chris McDonough) Date: Sat, 28 Nov 2009 15:03:35 -0500 Subject: [Web-SIG] http://wiki.python.org/moin/WebFrameworks In-Reply-To: <40498.81048.qm@web32001.mail.mud.yahoo.com> References: <40498.81048.qm@web32001.mail.mud.yahoo.com> Message-ID: <4B118217.3040707@plope.com> Aaron Watters wrote: >> On Thu, Nov 26, 2009 at 1:02 PM, Chris McDonough >> wrote: >>> http://wiki.python.org/moin/WebFrameworks >> seems to be the place where folks >>> are registering their respective web frameworks. >>> >>> I'd like to move some of the frameworks which are >> currently in the various >>> categories which haven't been active in a few years. >> In particular, I'd >>> like to move any framework which hasn't had a release >> since the beginning of >>> 2008 (arbitrary) into the "Discontinued / Inactive" >> framework category. I'd >>> be willing to do the work to make sure I wasn't moving >> one that actually >>> *did* have releases past that but just hadn't updated >> the page. >>> Any dissent? >>> >>> - C > > Why not call them "apparently stable" > versus "under active development"? Is the > cgi module "discontinued"? No, but the cgi module has undergone a lot of changes over the last couple of years which were present in Python releases: http://svn.python.org/view/python/branches/release26-maint/Lib/cgi.py?view=log > I'm a little sensitive on this topic > because people tell me that Gadfly is "inactive" > or "discontinued" > but it still does what it does > as documented very well. > > Frequent releases may actually be a sign of > bugginess and bad design. Agreed. On the other hand, though, no release for two years sometimes *does* mean it's dead. It's slightly unfair to the folks who are very actively improving a web framework to live in a "slot" on that page right next to actually-really-dead software because of the vagarities of lexical sorting. > If you suspect a project is really dead, maybe you > could try to contact the authors and ask about > what they think. Well, that was my intention. I don't want to remove *actually* active or stable-and-still-used packages from the list. Maybe I should just dial back the date to the beginning of 2007 or something. - C From exarkun at twistedmatrix.com Sun Nov 29 03:13:26 2009 From: exarkun at twistedmatrix.com (exarkun at twistedmatrix.com) Date: Sun, 29 Nov 2009 02:13:26 -0000 Subject: [Web-SIG] http://wiki.python.org/moin/WebFrameworks In-Reply-To: <4B118217.3040707@plope.com> References: <40498.81048.qm@web32001.mail.mud.yahoo.com> <4B118217.3040707@plope.com> Message-ID: <20091129021326.2549.389429268.divmod.xquotient.15@localhost.localdomain> On 28 Nov, 08:03 pm, chrism at plope.com wrote: >Well, that was my intention. I don't want to remove *actually* active >or stable-and-still-used packages from the list. Maybe I should just >dial back the date to the beginning of 2007 or something. Instead of trying to do this based on an arbitrary date, I'd suggest investigating the communities and developers for each project listed on the page. If no one is using the software, or the developers feel it would be appropriate to delist the software (or the developers are no longer responsive to communication attempts), then delisting it is probably a good idea. Otherwise, I think things should basically be left alone. Jean-Paul From ianb at colorstudy.com Sun Nov 29 04:17:00 2009 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 28 Nov 2009 21:17:00 -0600 Subject: [Web-SIG] http://wiki.python.org/moin/WebFrameworks In-Reply-To: <40498.81048.qm@web32001.mail.mud.yahoo.com> References: <40498.81048.qm@web32001.mail.mud.yahoo.com> Message-ID: Personally, if the author/maintainer of any library claims it is maintained/up-to-date, I say trust them. Most people are pretty honest about the status of their projects. But it does require a positive response to really make this claim. On Sat, Nov 28, 2009 at 12:03 PM, Aaron Watters wrote: > > > > > On Thu, Nov 26, 2009 at 1:02 PM, Chris McDonough > > wrote: > > > http://wiki.python.org/moin/WebFrameworks > > seems to be the place where folks > > > are registering their respective web frameworks. > > > > > > I'd like to move some of the frameworks which are > > currently in the various > > > categories which haven't been active in a few years. > > In particular, I'd > > > like to move any framework which hasn't had a release > > since the beginning of > > > 2008 (arbitrary) into the "Discontinued / Inactive" > > framework category. I'd > > > be willing to do the work to make sure I wasn't moving > > one that actually > > > *did* have releases past that but just hadn't updated > > the page. > > > > > > Any dissent? > > > > > > - C > > Why not call them "apparently stable" > versus "under active development"? Is the > cgi module "discontinued"? > > I'm a little sensitive on this topic > because people tell me that Gadfly is "inactive" > or "discontinued" > but it still does what it does > as documented very well. > > Frequent releases may actually be a sign of > bugginess and bad design. > If you suspect a project is really dead, maybe you > could try to contact the authors and ask about > what they think. > > -- Aaron Watters > > === > BTW, I think "Release early, release often" is nonsense > because it means you are probably releasing > something buggy and unstable which will just alienate > your users, who will never come back to see the better > version. > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/ianb%40colorstudy.com > -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Sun Nov 29 04:44:24 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Sun, 29 Nov 2009 14:44:24 +1100 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: <88e286470911271327p24dc978at5ee46e3ad1c99220@mail.gmail.com> References: <88e286470911271327p24dc978at5ee46e3ad1c99220@mail.gmail.com> Message-ID: <88e286470911281944s1a926ccaq600682e8aa573912@mail.gmail.com> After reading my prior blog posts where I explained my reasoning behind the changes, I will acknowledge that I haven't explained some stuff very well and people are failing to understand or getting wrong idea about why something is being suggested. I still believe there are though underlying problems there in the WSGI specification and right now, more by luck than design is various stuff working. In some cases such as readline(), the majority of WSGI applications/frameworks are in violation of the WSGI 1.0 specification due to their reliance on cgi.FieldStorage which makes calls to readline() with an argument. Either way, since there seemed to be objections at some level on every point, and since I really really have no enthusiasm for this stuff any more or of fighting for any change, I retract my personal interest in having any of the amendments as part of a WSGI 1.1 specification and will remove all that detail from mod_wsgi documentation. I will instead replace it with a separate page describing mod_wsgi compliance with WSGI 1.0 specification and highlighting those specific features which are in common, or not so common use, via mod_wsgi and which actually mean that people are writing applications incompatible with the WSGI 1.0 specification. To ensure compliance I could well raise Python exceptions for any use which isn't WSGI 1.0 compliant, but I have already learnt from where I tried get people to write portable WSGI applications by giving errors on certain use of stdin and stdout, that it is a pointless battle. All it got was a long list of users who believe mod_wsgi is broken even though if they read the actual documentation they would find it was their own software which was suspect or at least wasn't portable to all WSGI hosting mechanisms. This would only get worse if exceptions were raised for use of readline() with an argument and use of read() with no argument or argument of -1. Short story is that there are a fair few people who are just lazy, they will always write stuff the way the want to and not how it should be written. They will always blame other peoples code for being wrong before acknowledging they themselves are wrong. The only answer I therefore need out of WEB-SIG is whether the qualifications about how Python 3.X is to be supported are going to be an amendment to WSGI 1.0 or as a separate WSGI 1.1 update and whether if the latter whether the WSGI 1.1 tag will also have meaning for Python 2.X. I need an answer to this so I know whether to withdraw mod_wsgi 3.0 from download and replace it with a mod_wsgi 4.0 which changes the wsgi.version tuple being passed, for both Python 2.X and Python 3.X, from (1, 1) back to original (1, 0), given that some opinion seems to be that any interface changes can only really be performed as part of WSGI 2.0 and so I would be wrong in using (1, 1). If don't see an answer, then guess I will just have to revert it back to (1, 0) to be safe and to avoid any accusations that am highjacking the process. An answer sooner rather than later would be appreciated on the wsgi.version issue. Graham 2009/11/28 Graham Dumpleton : > Please ensure you have also all read: > > http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html > > I will post again later in detail when have some time to explain a few > more points not mentioned in that post and where people aren't quite > understanding the reasoning for doing things. > > One very quick comment about read(). > > Allowing read() with no argument is no different to a user saying > read(environ['CONTENT_LENGTH']). Because a WSGI adapter/middleware is > going to have to track bytes read to ensure can return an empty string > as end sentinel, it will know length remaining and would internally > for read() with no argument do read(remaining_bytes). As such no real > differences in inefficiencies as far as memory use goes for > implementing read() because of need to implement end sentinel. > > Also, you have concerns about read() with no argument, but frankly > readline() with no argument, which is already required, is much worse > because you cant really track bytes read and just read to end of > input. This is because they only want to read to end of line and so > reading all input is going to blow out memory use unreasonably as you > speculate for read(). As such, a readline() implementation is likely > to read in blocks and internally buffer where read() doesn't > necessarily have to. > > It may also be pertinent to read: > > http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html > > as from memory it talks about issues with not paying attention to > Content-Length on output filtering middleware as well. > > As I said, will reply later when have some time to focus. Right now I > have a 2 year old to keep amused. > > Graham > > 2009/11/27 James Y Knight : >> I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the official definition of WSGI 1.1, which describes how to implement WSGI adapters for both Python 2.x and 3.x. It may not be perfect, but, it's been implemented twice, and seems ot have no fatal flaws (it doesn't do any lossy transforms, so any issues are irritations at worst). The basis for this definition is also described in the "WSGI 1.0 Ammendments" [2] page. >> >> The definitions as they stand are clear enough to understand and implement, but not currently in spec-worthy language. (e.g. it says "should" and "may" in a colloquial fashion, but actually means MUST in some places and SHOULD in others, as defined by RFC 2119) >> >> Thus, I'd like to suggest that Graham (if he's willing?) should reformat the "Definition"/"Ammendments" as an actual diff against the current PEP 333. Then, I will recommend adopting that document as an actual standard WSGI 1.1, to replace PEP 333. >> >> This discussion has gone on long enough, and it doesn't really matter as much to have the perfect API, as it does to have a standard. >> >> James >> >> [1] http://code.google.com/p/modwsgi/wiki/SupportForPython3X >> [2] http://www.wsgi.org/wsgi/Amendments_1.0 >> >> _______________________________________________ >> Web-SIG mailing list >> Web-SIG at python.org >> Web SIG: http://www.python.org/sigs/web-sig >> Unsubscribe: http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com >> > From graham.dumpleton at gmail.com Sun Nov 29 05:28:26 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Sun, 29 Nov 2009 15:28:26 +1100 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: <88e286470911281944s1a926ccaq600682e8aa573912@mail.gmail.com> References: <88e286470911271327p24dc978at5ee46e3ad1c99220@mail.gmail.com> <88e286470911281944s1a926ccaq600682e8aa573912@mail.gmail.com> Message-ID: <88e286470911282028o5849c853od3b8239cc59f8d00@mail.gmail.com> 2009/11/29 Graham Dumpleton : > After reading my prior blog posts where I explained my reasoning > behind the changes, I will acknowledge that I haven't explained some > stuff very well and people are failing to understand or getting wrong > idea about why something is being suggested. > > I still believe there are though underlying problems there in the WSGI > specification and right now, more by luck than design is various stuff > working. In some cases such as readline(), the majority of WSGI > applications/frameworks are in violation of the WSGI 1.0 specification > due to their reliance on cgi.FieldStorage which makes calls to > readline() with an argument. > > Either way, since there seemed to be objections at some level on every > point, and since I really really have no enthusiasm for this stuff any > more or of fighting for any change, I retract my personal interest in > having any of the amendments as part of a WSGI 1.1 specification and > will remove all that detail from mod_wsgi documentation. I will > instead replace it with a separate page describing mod_wsgi compliance > with WSGI 1.0 specification and highlighting those specific features > which are in common, or not so common use, via mod_wsgi and which > actually mean that people are writing applications incompatible with > the WSGI 1.0 specification. > > To ensure compliance I could well raise Python exceptions for any use > which isn't WSGI 1.0 compliant, but I have already learnt from where I > tried get people to write portable WSGI applications by giving errors > on certain use of stdin and stdout, that it is a pointless battle. All > it got was a long list of users who believe mod_wsgi is broken even > though if they read the actual documentation they would find it was > their own software which was suspect or at least wasn't portable to > all WSGI hosting mechanisms. This would only get worse if exceptions > were raised for use of readline() with an argument and use of read() > with no argument or argument of -1. Short story is that there are a > fair few people who are just lazy, they will always write stuff the > way the want to and not how it should be written. They will always > blame other peoples code for being wrong before acknowledging they > themselves are wrong. > > The only answer I therefore need out of WEB-SIG is whether the > qualifications about how Python 3.X is to be supported are going to be > an amendment to WSGI 1.0 or as a separate WSGI 1.1 update and whether > if the latter whether the WSGI 1.1 tag will also have meaning for > Python 2.X. > > I need an answer to this so I know whether to withdraw mod_wsgi 3.0 > from download and replace it with a mod_wsgi 4.0 which changes the > wsgi.version tuple being passed, for both Python 2.X and Python 3.X, > from (1, 1) back to original (1, 0), given that some opinion seems to > be that any interface changes can only really be performed as part of > WSGI 2.0 and so I would be wrong in using (1, 1). > > If don't see an answer, then guess I will just have to revert it back > to (1, 0) to be safe and to avoid any accusations that am highjacking > the process. > > An answer sooner rather than later would be appreciated on the > wsgi.version issue. Answering my own question, it is actually obvious that it has to be called (1, 0). This is because wsgiref in Python 3.X already calls it (1, 0) and don't have much choice to be in agreement with that. I will therefore replace mod_wsgi 3.0 with a 4.0 release that reverts it to (1, 0) from (1, 1) and all the other stuff about amendments can be ignored. Graham > 2009/11/28 Graham Dumpleton : >> Please ensure you have also all read: >> >> http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html >> >> I will post again later in detail when have some time to explain a few >> more points not mentioned in that post and where people aren't quite >> understanding the reasoning for doing things. >> >> One very quick comment about read(). >> >> Allowing read() with no argument is no different to a user saying >> read(environ['CONTENT_LENGTH']). Because a WSGI adapter/middleware is >> going to have to track bytes read to ensure can return an empty string >> as end sentinel, it will know length remaining and would internally >> for read() with no argument do read(remaining_bytes). As such no real >> differences in inefficiencies as far as memory use goes for >> implementing read() because of need to implement end sentinel. >> >> Also, you have concerns about read() with no argument, but frankly >> readline() with no argument, which is already required, is much worse >> because you cant really track bytes read and just read to end of >> input. This is because they only want to read to end of line and so >> reading all input is going to blow out memory use unreasonably as you >> speculate for read(). As such, a readline() implementation is likely >> to read in blocks and internally buffer where read() doesn't >> necessarily have to. >> >> It may also be pertinent to read: >> >> http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html >> >> as from memory it talks about issues with not paying attention to >> Content-Length on output filtering middleware as well. >> >> As I said, will reply later when have some time to focus. Right now I >> have a 2 year old to keep amused. >> >> Graham >> >> 2009/11/27 James Y Knight : >>> I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the official definition of WSGI 1.1, which describes how to implement WSGI adapters for both Python 2.x and 3.x. It may not be perfect, but, it's been implemented twice, and seems ot have no fatal flaws (it doesn't do any lossy transforms, so any issues are irritations at worst). The basis for this definition is also described in the "WSGI 1.0 Ammendments" [2] page. >>> >>> The definitions as they stand are clear enough to understand and implement, but not currently in spec-worthy language. (e.g. it says "should" and "may" in a colloquial fashion, but actually means MUST in some places and SHOULD in others, as defined by RFC 2119) >>> >>> Thus, I'd like to suggest that Graham (if he's willing?) should reformat the "Definition"/"Ammendments" as an actual diff against the current PEP 333. Then, I will recommend adopting that document as an actual standard WSGI 1.1, to replace PEP 333. >>> >>> This discussion has gone on long enough, and it doesn't really matter as much to have the perfect API, as it does to have a standard. >>> >>> James >>> >>> [1] http://code.google.com/p/modwsgi/wiki/SupportForPython3X >>> [2] http://www.wsgi.org/wsgi/Amendments_1.0 >>> >>> _______________________________________________ >>> Web-SIG mailing list >>> Web-SIG at python.org >>> Web SIG: http://www.python.org/sigs/web-sig >>> Unsubscribe: http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com >>> >> > From foom at fuhm.net Sun Nov 29 06:40:17 2009 From: foom at fuhm.net (James Y Knight) Date: Sun, 29 Nov 2009 00:40:17 -0500 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: <88e286470911281944s1a926ccaq600682e8aa573912@mail.gmail.com> References: <88e286470911271327p24dc978at5ee46e3ad1c99220@mail.gmail.com> <88e286470911281944s1a926ccaq600682e8aa573912@mail.gmail.com> Message-ID: <01CC6582-B272-4CC8-B87A-95B683965FB2@fuhm.net> On Nov 28, 2009, at 10:44 PM, Graham Dumpleton wrote: > Either way, since there seemed to be objections at some level on every > point, and since I really really have no enthusiasm for this stuff any > more or of fighting for any change, I retract my personal interest in > having any of the amendments as part of a WSGI 1.1 specification and > will remove all that detail from mod_wsgi documentation [...] > If don't see an answer, then guess I will just have to revert it back > to (1, 0) to be safe and to avoid any accusations that am highjacking > the process. > > An answer sooner rather than later would be appreciated on the > wsgi.version issue. I'd rather appreciate it if you held off on making such changes until either this discussion either peters out or is resolved. You sound somewhat negative, but it seems to me that there's actually quite close to being a consensus on adopting most of your proposal. Changing the proposal out from under us doesn't really help things. The next step here is clearly for someone to redraft the changes as a diff against PEP 333. If you do not have any interest in being that person, please make that clear, so someone else can step up to do so. James From graham.dumpleton at gmail.com Sun Nov 29 06:47:24 2009 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Sun, 29 Nov 2009 16:47:24 +1100 Subject: [Web-SIG] Move to bless Graham's WSGI 1.1 as official spec In-Reply-To: <01CC6582-B272-4CC8-B87A-95B683965FB2@fuhm.net> References: <88e286470911271327p24dc978at5ee46e3ad1c99220@mail.gmail.com> <88e286470911281944s1a926ccaq600682e8aa573912@mail.gmail.com> <01CC6582-B272-4CC8-B87A-95B683965FB2@fuhm.net> Message-ID: <88e286470911282147k734b9ef6pf8bf47140c554793@mail.gmail.com> 2009/11/29 James Y Knight : > On Nov 28, 2009, at 10:44 PM, Graham Dumpleton wrote: >> Either way, since there seemed to be objections at some level on every >> point, and since I really really have no enthusiasm for this stuff any >> more or of fighting for any change, I retract my personal interest in >> having any of the amendments as part of a WSGI 1.1 specification and >> will remove all that detail from mod_wsgi documentation > > > [...] > >> If don't see an answer, then guess I will just have to revert it back >> to (1, 0) to be safe and to avoid any accusations that am highjacking >> the process. >> >> An answer sooner rather than later would be appreciated on the >> wsgi.version issue. > > I'd rather appreciate it if you held off on making such changes until either this discussion either peters out or is resolved. You sound somewhat negative, but it seems to me that there's actually quite close to being a consensus on adopting most of your proposal. Changing the proposal out from under us doesn't really help things. > > The next step here is clearly for someone to redraft the changes as a diff against PEP 333. If you do not have any interest in being that person, please make that clear, so someone else can step up to do so. No I do not want a part in drafting any changes, I just want to move on from all this stuff and starting working on other projects. Since though some don't seem to understand the reasons for the changes then you will find it hard to find some who is in a position to be able to do them. You probably really are just better off worrying about Python 3.X support and accept that tinkering at edges of WSGI 1.0 on other issues is not going to solve all the WSGI issues. As PJE suggest, leave that to an interface incompatible update so that you don't have this whole problem of what version existing components support. Graham From mborch at gmail.com Tue Nov 24 23:09:03 2009 From: mborch at gmail.com (Malthe Borch) Date: Tue, 24 Nov 2009 22:09:03 -0000 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> Message-ID: 2009/11/24 Ian Bicking : > Why does this matter? It's all convention, but the CGI interpretation was to read the HTTP request line by line until a blank line came and that was the environment. Everything after that is the body. If you want to obtain a shorter call signature ? e.g. (environ, start_response) instead of (environ, body, start_response), that's fine; but maybe this should be a decorator. You could take this argument further and do this in two steps (leaving out ``start_response`` in the following): (stream,) => (cgi_environ, body) => (hybrid_environ,) That would preserve all information. Why does it matter? This is the single most difficult question to answer in software design because it's a matter of balance. On the one hand we strive to find the best abstractions to express our problems which will eventually be serialized into one or more tracks of assembler code. On the other, we must be pragmatic and stop our quest in time to still get things done in reasonable time. I'm not sure the balance is in favor of the hybrid model; when you google "environ http" you don't see a lot of body input stream in there. You don't see "multi-threading" in there either; however, in the WSGI environment, you do! We just put it there, because we don't know where else to put it! Unable to find or respect the abtractions, we are lucky to have Python's versatile dictionary. The downside: bitrot. \malthe From henry at precheur.org Tue Nov 24 23:26:24 2009 From: henry at precheur.org (Henry Precheur) Date: Tue, 24 Nov 2009 22:26:24 -0000 Subject: [Web-SIG] Future of WSGI In-Reply-To: References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> Message-ID: <20091124222507.GA23879@banane.novuscom.net> On Tue, Nov 24, 2009 at 10:50:00PM +0100, Malthe Borch wrote: > How people use or abuse software is not our concern; but the standard > library should not itself abuse its own abstractions. Your assumption is that `environ` == HTTP headers. That's simply NOT the case. A request is: - A request line - Some headers - A body (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`. If you really want to separate the headers from the rest you would put another dictionary containing the headers inside `environ`. Instead WSGI puts the headers prefixed with HTTP_ in `environ`, because that's what CGI is doing. It might not be 100% clean, or logic, but it's SIMPLER, there's no need to deal with nested dictionaries or other more complex structure, and it's extensible. > Request = namedtuple("Request", "environ body") > Response = namedtuple("Response", "status headers iterable") > > Iterable might be "body" or "chunks" or some other term. namedtuple is Python 2.6+: WSGI can't use it. WSGI must work w/ older versions of Python. -- Henry Pr?cheur From mborch at gmail.com Tue Nov 24 23:37:13 2009 From: mborch at gmail.com (Malthe Borch) Date: Tue, 24 Nov 2009 22:37:13 -0000 Subject: [Web-SIG] Future of WSGI In-Reply-To: <20091124222507.GA23879@banane.novuscom.net> References: <4B0BA030.5010201@gmail.com> <4B0C4FFF.5070305@gmail.com> <20091124222507.GA23879@banane.novuscom.net> Message-ID: 2009/11/24 Henry Precheur : > (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. > If you really want to separate the headers from the rest you would put > another dictionary containing the headers inside `environ`. Instead WSGI > puts the headers prefixed with HTTP_ in `environ`, because that's what > CGI is doing. It might not be 100% clean, or logic, but it's SIMPLER, > there's no need to deal with nested dictionaries or other more complex > structure, and it's extensible. I don't mind those. CGI does it too, like you say. > 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. \malthe