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
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
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
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
At 04:39 PM 1/9/2011 -0800, Alice BevanMcGregor 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
At 05:06 PM 1/9/2011 -0800, Alice BevanMcGregor 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
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
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
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
- 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
10 matches
Mail list logo