Re: [Web-SIG] Python 3 / PEP 3333 (was: PEP 444 / WSGI 2 Async)

On 2011-01-06 23:40:53 -0800, Graham Dumpleton said: There is also uWSGI and CherryPy WSGI server. I recollect that Benoit may have started looking it over for gunicorn. Ah, right, I recall seeing CherryPy mentioned in archived discussions. So there's hope, then, for relatively quick adoptio

Re: [Web-SIG] Python 3 / PEP 3333 (was: PEP 444 / WSGI 2 Async)

On 7 January 2011 18:23, Alice Bevan–McGregor wrote: > On 2011-01-06 21:35:24 -0800, Jacob Kaplan-Moss said: > Other than mod_wsgi, are there any PEP -compliant (or near-compliant) > components in the wild?  Enough to bring a framework to life in Python 3? >  What I see is the chicken-and-egg

[Web-SIG] Python 3 / PEP 3333 (was: PEP 444 / WSGI 2 Async)

On 2011-01-06 21:35:24 -0800, Jacob Kaplan-Moss said: And I'm feeling incredibly disheartened. As the author of my own small WSGI framework (with world-wide, though still limited use) I have the luxury of being able to embrace experimental technologies. The lack of WSGI capability in Python

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 7 January 2011 17:19, Alice Bevan–McGregor wrote: >> -                    raise exc_info[0], exc_info[1], exc_info[2] >> +                    raise >> exc_info[0](exc_info[1]).with_traceback(exc_info[2]) > > The exception raising syntax has changed; you can not re-raise an exception > using tup

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 7 January 2011 17:22, Graham Dumpleton wrote: > On 7 January 2011 17:13, Graham Dumpleton wrote: >> The version at: >> >> http://svn.python.org/projects/peps/trunk/pep-.txt >> >> still shows: >> >>        elif not headers_sent: >>             # Before the first output, send the stored head

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 7 January 2011 17:13, Graham Dumpleton wrote: > The version at: > > http://svn.python.org/projects/peps/trunk/pep-.txt > > still shows: > >        elif not headers_sent: >             # Before the first output, send the stored headers >             status, response_headers = headers_sent[:]

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On 2011-01-06 22:00:17 -0800, Graham Dumpleton said: -environ = {k: wsgi_string(v) for k,v in os.environ.items()} +environ = {k: wsgi_string(v) for k,v in list(os.environ.items())} 2to3 takes the conservative route of assuming your application treats dict.items() as a list in all cases

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

The version at: http://svn.python.org/projects/peps/trunk/pep-.txt still shows: elif not headers_sent: # Before the first output, send the stored headers status, response_headers = headers_sent[:] = headers_set sys.stdout.write('Status: %s\r\n'

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Stupid question first. When running 2to3 on the example CGI code, why would it throw back the following. Is this indicative of anything else that needs to be changed to satisfy some Python 3 thing. The list() bit seems redundant, but I don't know what the other stuff is about. --- xx.py (original)

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight wrote: > On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote: >> At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote: >>> Is that the last thing or do I need to go spend some time and write my >>> own CGI/WSGI bridge for Python 3 based on my own Python 2 one I

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote: > At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote: >> Is that the last thing or do I need to go spend some time and write my >> own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have >> lying around and just do some final validation chec

Re: [Web-SIG] PEP 444 / WSGI 2 Async

On Thu, Jan 6, 2011 at 7:47 PM, Alice Bevan–McGregor wrote: > All input is welcome; I do want to hear from both framework developers and > users of frameworks. OK, here's my input. I'm not comfortable speaking on behalf of the entire Django core team, but I am consciously wearing my Django BDFL h

Re: [Web-SIG] PEP 444 Goals

On 2011-01-06 21:26:32 -0800, James Y Knight said: You've misread that section. In HTTP/1.0, *requests* were required to have a Content-Length if they had a body (HTTP 1.1 fixed that with chunked request support). Responses have never had that restriction: they have always (even since before HT

Re: [Web-SIG] PEP 444 / WSGI 2 Async

On Thu, Jan 6, 2011 at 8:49 PM, P.J. Eby wrote: > At 05:47 PM 1/6/2011 -0800, Alice Bevan­McGregor wrote: >> >> Tossing the idea around all day long will then, of course, be happening >> regardless.  Unfortunately for that particular discussion, PEP 3148 / >> Futures seems to have won out in the b

Re: [Web-SIG] PEP 444 Goals

On Jan 7, 2011, at 12:13 AM, Alice Bevan–McGregor wrote: > On 2011-01-06 14:14:32 -0800, Alice Bevan–McGregor said: >> There was something, somewhere I was reading related to WSGI about requiring >> content-length... but no matter. > > Right, I remember now: the HTTP 1.0 specification. (Honest

Re: [Web-SIG] PEP 444 / WSGI 2 Async

07.01.2011 06:49, P.J. Eby kirjoitti: At 05:47 PM 1/6/2011 -0800, Alice Bevan­McGregor wrote: Tossing the idea around all day long will then, of course, be happening regardless. Unfortunately for that particular discussion, PEP 3148 / Futures seems to have won out in the broader scope. Do an

Re: [Web-SIG] PEP 444 Goals

On 2011-01-06 14:14:32 -0800, Alice Bevan–McGregor said: There was something, somewhere I was reading related to WSGI about requiring content-length... but no matter. Right, I remember now: the HTTP 1.0 specification. (Honestly not trying to sound sarcastic!) See: http://www.w3.or

Re: [Web-SIG] PEP 444 / WSGI 2 Async

At 05:47 PM 1/6/2011 -0800, Alice Bevan­McGregor wrote: Tossing the idea around all day long will then, of course, be happening regardless. Unfortunately for that particular discussion, PEP 3148 / Futures seems to have won out in the broader scope. Do any established async frameworks or serve

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote: Is that the last thing or do I need to go spend some time and write my own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have lying around and just do some final validation checks with a parallel implementation as a sanity check to

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

At 10:33 AM 1/4/2011 -0800, Guido van Rossum wrote: But the flush() I was referring to is actually *before* either of these, suggesting sys.stdout.flush() sys.stdout.buffer.write(data) sys.stdout.buffer.flush() However the first flush() is only necessary is there's a possibility that previously

Re: [Web-SIG] PEP 444 Goals

At 12:52 PM 1/6/2011 -0800, Alice Bevan­McGregor wrote: Ignoring async for the moment, the goals of the PEP 444 rewrite are: :: Clear separation of "narrative" from "rules to be followed". This allows developers of both servers and applications to easily run through a confomance "check list".

Re: [Web-SIG] PEP 444 Goals

07.01.2011 04:55, Graham Dumpleton kirjoitti: 2011/1/7 Alex Grönholm: 07.01.2011 04:09, Graham Dumpleton kirjoitti: 2011/1/7 Graham Dumpleton: 2011/1/7 Alex Grönholm: 07.01.2011 01:14, Graham Dumpleton kirjoitti: One other comment about HTTP/1.1 features. You will always be battling to have

Re: [Web-SIG] PEP 444 Goals

2011/1/7 James Y Knight : > > On Jan 6, 2011, at 7:46 PM, Alex Grönholm wrote: > > The WebDAV spec, on the other hand, says > (http://www.webdav.org/specs/rfc2518.html#STATUS_102): > > The 102 (Processing) status code is an interim response used to inform the > client that the server has accepted t

Re: [Web-SIG] PEP 444 Goals

On Jan 6, 2011, at 7:46 PM, Alex Grönholm wrote: > The WebDAV spec, on the other hand, says > (http://www.webdav.org/specs/rfc2518.html#STATUS_102): > > The 102 (Processing) status code is an interim response used to inform the > client that the server has accepted the complete request, but ha

Re: [Web-SIG] PEP 444 Goals

2011/1/7 Alex Grönholm : > 07.01.2011 04:09, Graham Dumpleton kirjoitti: >> >> 2011/1/7 Graham Dumpleton: >>> >>> 2011/1/7 Alex Grönholm: 07.01.2011 01:14, Graham Dumpleton kirjoitti: One other comment about HTTP/1.1 features. You will always be battling to have some H

Re: [Web-SIG] PEP 444 Goals

07.01.2011 04:09, Graham Dumpleton kirjoitti: 2011/1/7 Graham Dumpleton: 2011/1/7 Alex Grönholm: 07.01.2011 01:14, Graham Dumpleton kirjoitti: One other comment about HTTP/1.1 features. You will always be battling to have some HTTP/1.1 features work in a controllable way. This is because WSGI

Re: [Web-SIG] PEP 444 Goals

2011/1/7 Graham Dumpleton : > 2011/1/7 Alex Grönholm : >> 07.01.2011 01:14, Graham Dumpleton kirjoitti: >> >> One other comment about HTTP/1.1 features. >> >> You will always be battling to have some HTTP/1.1 features work in a >> controllable way. This is because WSGI gateways/adapters aren't ofte

Re: [Web-SIG] PEP 444 / WSGI 2 Async

On 2011-01-06 09:20:48 -0800, Randy Syring said: Being a web application developer and relying on frameworks like Werkzeug and WebOb, I may not have much of a dog in this fight. All input is welcome; I do want to hear from both framework developers and users of frameworks. I suspect this disc

Re: [Web-SIG] PEP 444 Goals

2011/1/7 Alex Grönholm : > 07.01.2011 01:14, Graham Dumpleton kirjoitti: > > One other comment about HTTP/1.1 features. > > You will always be battling to have some HTTP/1.1 features work in a > controllable way. This is because WSGI gateways/adapters aren't often > directly interfacing with the ra

Re: [Web-SIG] PEP 444 Goals

07.01.2011 01:14, Graham Dumpleton kirjoitti: One other comment about HTTP/1.1 features. You will always be battling to have some HTTP/1.1 features work in a controllable way. This is because WSGI gateways/adapters aren't often directly interfacing with the raw HTTP layer, but with FASTCGI, SCGI

Re: [Web-SIG] PEP 444 / WSGI 2 Async

06.01.2011 23:11, Sylvain Hellegouarch kirjoitti: 2011/1/6 Alex Grönholm > 06.01.2011 20:02, Eric Larson kirjoitti: At Thu, 6 Jan 2011 13:03:15 + (GMT), chris dent wrote: On async: I agree with so

Re: [Web-SIG] PEP 444 Goals

One other comment about HTTP/1.1 features. You will always be battling to have some HTTP/1.1 features work in a controllable way. This is because WSGI gateways/adapters aren't often directly interfacing with the raw HTTP layer, but with FASTCGI, SCGI, AJP, CGI etc. In this sort of situation you ar

Re: [Web-SIG] Declaring PEP 3333 accepted (was: PEP 444 != WSGI 2.0)

Can we not let the PEP 444 discussion side track getting PEP sorted out? This is exactly what has happened numerous times before when we have been trying to sort out core issues of WSGI on Python 3. And people wander why I get grumpy now every time this happens. :-( So, where are we at? It se

Re: [Web-SIG] PEP 444 Goals

On 7 January 2011 08:56, Alice Bevan–McGregor wrote: > On 2011-01-06 13:06:36 -0800, James Y Knight said: > >> On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote: >>> >>> :: Making optional (and thus rarely-implemented) features non-optional. >>> E.g. server support for HTTP/1.1 with clarifica

Re: [Web-SIG] PEP 444 Goals

On 2011-01-06 14:01:09 -0800, James Y Knight said: No you don't -- HTTP 1.0 allows indeterminate-length output. The server simply must close the connection to indicate the end of the response if either the client version HTTP/1.0, or the server doesn't implement HTTP/1.1. Ah, you are correct

[Web-SIG] WSGI Middleware Dependancy Graphing (was: PEP 444 / WSGI 2 Async)

On 2011-01-06 13:08:04 -0800, Robert Brewer said: Or, if you had actually read what I wrote weeks ago... I did. Apologies for forgetting the detail of the implementation being deprecated. We don't need Yet Another Way of hooking in processing components; if anything, we need a standard me

Re: [Web-SIG] PEP 444 Goals

On Jan 6, 2011, at 4:56 PM, Alice Bevan–McGregor wrote: > On 2011-01-06 13:06:36 -0800, James Y Knight said: > >> On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote: >>> :: Making optional (and thus rarely-implemented) features non-optional. >>> E.g. server support for HTTP/1.1 with clarifi

Re: [Web-SIG] PEP 444 Goals

On 2011-01-06 13:06:36 -0800, James Y Knight said: On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote: :: Making optional (and thus rarely-implemented) features non-optional. E.g. server support for HTTP/1.1 with clarifications for interfacing applications to 1.1 servers. Thus pipelining,

Re: [Web-SIG] PEP 444 / WSGI 2 Async

2011/1/6 Alex Grönholm > 06.01.2011 20:02, Eric Larson kirjoitti: > >> At Thu, 6 Jan 2011 13:03:15 + (GMT), >> chris dent wrote: >> >>> >>> On async: >>> >>> I agree with some others who have suggested that maybe async should be >>> its own thing, rather than integrated into a WSGI2. A serve

Re: [Web-SIG] PEP 444 / WSGI 2 Async

Alice Bevan–McGregor wrote: > chris.d...@gmail.com said: > > I can't get my head around filters yet... > > It isn't necessary; it is, however, an often re-implemented feature of > a framework on top of WSGI. CherryPy, Paste, Django, etc. all > implement some form of non-WSGI (or, hell, Paste uses

Re: [Web-SIG] PEP 444 Goals

On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote: > :: Making optional (and thus rarely-implemented) features non-optional. E.g. > server support for HTTP/1.1 with clarifications for interfacing applications > to 1.1 servers. Thus pipelining, chunked encoding, et. al. as per the HTTP > 1.

Re: [Web-SIG] PEP 444 / WSGI 2 Async

06.01.2011 20:02, Eric Larson kirjoitti: At Thu, 6 Jan 2011 13:03:15 + (GMT), chris dent wrote: On async: I agree with some others who have suggested that maybe async should be its own thing, rather than integrated into a WSGI2. A server could choose to be WSGI2 compliant or AWSGI complian

Re: [Web-SIG] PEP 444 Goals

It seems to me that the spec that Alice is working on could be something great but the problems are not well defined (in the PEP). This causes confusion about what the goals are. For completeness sake, here's a slightly simplified Abstract: :: A proposed second-generation standard interface b

Re: [Web-SIG] PEP 444 / WSGI 2 Async

On 2011-01-06 09:06:10 -0800, chris.d...@gmail.com said: I wasn't actually talking about the log dump. That was useful. What I was talking about were earlier messages in the thread where people were making responses, quoting vast swaths of text for no clear reason. Ah. :) I do make an effort

[Web-SIG] PEP 444 Goals

Hello web-sig. My name is Timothy Farrell. I'm the developer of the Rocket web server. I understand that most of you are more experienced and passionate than myself. But I'm come here because I want to see certain things standardized. I'm pretty new to this forum but I've read through all t

Re: [Web-SIG] PEP 444 / WSGI 2 Async

Alice Bevan–McGregor writes: > > Er, for the record, in Python 3 non-blocking file objects return None when > > read() would block. > > -1 > > I'm aware, however that's not practically useful. How would you detect > from within the WSGI 2 application that the file object has become > readable

Re: [Web-SIG] PEP 444 / WSGI 2 Async

At Thu, 6 Jan 2011 13:03:15 + (GMT), chris dent wrote: > > On async: > > I agree with some others who have suggested that maybe async should be > its own thing, rather than integrated into a WSGI2. A server could > choose to be WSGI2 compliant or AWSGI compliant, or both. > +1 After seeing

Re: [Web-SIG] PEP 444 / WSGI 2 Async

Alice, Being a web application developer and relying on frameworks like Werkzeug and WebOb, I may not have much of a dog in this fight. However, I have been following web-sig for a couple years and I have seen the difficulties involved in reaching consensus on modifying/updating the WSGI spe

Re: [Web-SIG] PEP 444 / WSGI 2 Async

On Thu, 6 Jan 2011, Alice Bevan–McGregor wrote: Yeah; I knew the IRC log dump was only so useful. It's a lot of material to go through, and much of it was discussed at strange hours with little sleep. ;) I wasn't actually talking about the log dump. That was useful. What I was talking about

Re: [Web-SIG] PEP 444 / WSGI 2 Async

Chris, On 2011-01-06 05:03:15 -0800, Chris Dent said: On Wed, 5 Jan 2011, Alice Bevan–McGregor wrote: This should give a fairly comprehensive explanation of the rationale behind > some decisions in the rewrite; a version of these conversations (in narrative > style vs. discussion) will be adde

Re: [Web-SIG] PEP 444 / WSGI 2 Async

On 2011-01-06 03:53:14 -0800, Antoine Pitrou said: Alice Bevan-€“McGregor writes: GothAlice: ... native string usage, the definition of "byte string" as "the format returned by socket read" (which, on Java, is unicode!) ... Just so no-one feels the need to correct me; agronholm made sure I d

Re: [Web-SIG] PEP 444 / WSGI 2 Async

At 01:03 PM 1/6/2011 +, chris.d...@gmail.com wrote: Does that apply here? It seems you either allow unicode strings or you don't, not a certain subsection. That's why PEP requires bytes instead - only the application knows what it's sending, and the server and middleware shouldn't hav

Re: [Web-SIG] PEP 444 / WSGI 2 Async

On Wed, 5 Jan 2011, Alice Bevan–McGregor wrote: This should give a fairly comprehensive explanation of the rationale behind some decisions in the rewrite; a version of these conversations (in narrative style vs. discussion) will be added to the rewrite Real Soon Now™ under the Rationale secti

Re: [Web-SIG] PEP 444 / WSGI 2 Async

Alice Bevan–McGregor writes: > > agronholm: what new features does pep 444 propose to add to pep ? \ > async, filters, no buffering? > > GothAlice: Async, filters, no server-level buffering, native string > usage, the definition of "byte string" as "the format returned by > socket read" (