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

[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

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 the

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

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. PEP

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

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

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

2011-01-10 Thread Timothy Farrell
- Original Message - From: P.J. Eby p...@telecommunity.com To: Timothy Farrell tfarr...@owassobible.org, 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