Re: [Web-SIG] Server-side async API implementation sketches

2011-01-10 Thread chris . dent
On Sun, 9 Jan 2011, Alice Bevan–McGregor wrote: On 2011-01-09 09:03:38 -0800, P.J. Eby said: Hm. I'm not sure if I like that. The typical app developer really shouldn't be yielding multiple body strings in the first place. Wait; what? So you want the app developer to load a 40MB talkcast M

[Web-SIG] Generator-Based Applications: Marrow HTTPd Example

2011-01-10 Thread Alice Bevan–McGregor
Howdy! Here's a rewritten (and incomplete, but GET and HEAD requests work fine) marrow.server.http branch [1] that illustrates a simple application [2] and protocol implementation [3]. Most notably, examine the 'resume' method [4]. The 'basic' example yields a future instance and uses the d

Re: [Web-SIG] Generator-Based Applications: Marrow HTTPd Example

2011-01-10 Thread Massimo Di Pierro
I like this a lot! On Jan 10, 2011, at 6:25 AM, Alice Bevan–McGregor wrote: > Howdy! > > Here's a rewritten (and incomplete, but GET and HEAD requests work fine) > marrow.server.http branch [1] that illustrates a simple application [2] and > protocol implementation [3]. Most notably, examine

Re: [Web-SIG] Server-side async API implementation sketches

2011-01-10 Thread James Y Knight
On Jan 10, 2011, at 4:48 AM, chris.d...@gmail.com wrote: > My reaction too. I've read this elsewhere on this list too, in other > topics. A general statement that the correct way to make an > efficient WSGI (1) app is to return just one body string. > > This runs contrary to everything I've ever

Re: [Web-SIG] Server-side async API implementation sketches

2011-01-10 Thread P.J. Eby
At 04:39 PM 1/9/2011 -0800, Alice Bevan­McGregor wrote: On 2011-01-09 09:26:19 -0800, P.J. Eby said: If wsgi.input offers any synchronous methods... Regardless of whether or not wsgi.input is implemented in an async way, wrap it in a future and eventually get around to yielding it. Problem

Re: [Web-SIG] Server-side async API implementation sketches

2011-01-10 Thread P.J. Eby
At 05:06 PM 1/9/2011 -0800, Alice Bevan­McGregor wrote: On 2011-01-09 09:03:38 -0800, P.J. Eby said: Hm. I'm not sure if I like that. The typical app developer really shouldn't be yielding multiple body strings in the first place. Wait; what? So you want the app developer to load a 40MB tal

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

2011-01-10 Thread Guido van Rossum
Ok, now that we've had a week of back and forth about this, let me repeat my "threat". Unless more concerns are brought up in the next 24 hours, can PEP be accepted? It seems a lot of people are waiting for a decision that enables implementers to go ahead and claim PEP 333[3] compatibility. PE

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

2011-01-10 Thread Alice Bevan–McGregor
On 2011-01-10 13:12:57 -0800, Guido van Rossum said: Ok, now that we've had a week of back and forth about this, let me repeat my "threat". Unless more concerns are brought up in the next 24 hours, can PEP be accepted? +9001 (> 9000) It seems a lot of people are waiting for a decision t

Re: [Web-SIG] Generator-Based Applications: Marrow HTTPd Example

2011-01-10 Thread Alice Bevan–McGregor
On 2011-01-10 04:25:40 -0800, Alice Bevan–McGregor said: Note that this particular rewrite is not complete, nor has it been profiled and optimized; initial benchmarks (using the 'benchmark' example) show a reduction of ~600 RSecs from the 'draft' branch, which is substantial, but hasn't been t

Re: [Web-SIG] PEP 444 feature request - Futures executor

2011-01-10 Thread Timothy Farrell
- Original Message - From: "P.J. Eby" To: "Timothy Farrell" , web-sig@python.org Sent: Friday, January 7, 2011 2:14:20 PM Subject: Re: [Web-SIG] PEP 444 feature request - Futures executor > There are some other issues that might need to be addressed, like > maybe adding an attribute or t