Re: [Web-SIG] PEP 444 and asynchronous support, continued

17.01.2011 06:47, Glyph Lefkowitz kirjoitti: On Jan 16, 2011, at 10:49 PM, Alex Grönholm wrote: After a weekend of experimentation with several asynchronous frameworks including gevent, tornado and twisted (and writing one myself too), and these are my findings so far: - asynchronous socket

Re: [Web-SIG] PEP 444 and asynchronous support, continued

On Jan 16, 2011, at 10:49 PM, Alex Grönholm wrote: > After a weekend of experimentation with several asynchronous frameworks > including gevent, tornado and twisted (and writing one myself too), and these > are my findings so far: > > - asynchronous socket implementations vary wildly across dif

[Web-SIG] PEP 444 and asynchronous support, continued

After a weekend of experimentation with several asynchronous frameworks including gevent, tornado and twisted (and writing one myself too), and these are my findings so far: - asynchronous socket implementations vary wildly across different frameworks - gevent is the fastest, tornado comes se

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

At 09:11 PM 1/10/2011 -0600, Timothy Farrell wrote: PJ, You seem to be old-hat at this so I'm looking for a little advise as I draft this spec. It seems a bad idea to me to just say environ['wsgi.executor'] will be a wrapped futures executor because the api handled by the executor can and li

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

org Sent: Tuesday, January 11, 2011 2:28:55 AM Subject: Re: [Web-SIG] PEP 444 feature request - Futures executor On Tue, Jan 11, 2011 at 10:40 AM, Timothy Farrell wrote: > - Original Message - > From: "P.J. Eby" > To: "Timothy Farrell" , web-sig@python.org &g

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

- 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 > ma

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

Here's what I've mutated Alex Grönholm's minimal middleware example into: (see the change history for the evolution of this) https://gist.github.com/771398 A complete functional (as in function, not working ;) async-capable middleware layer (that does nothing) is 12 lines. That, I thi

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

On 9 January 2011 12:16, Alice Bevan–McGregor wrote: > On 2011-01-08 09:00:18 -0800, P.J. Eby said: > >> (The next interesting challenge would be to integrate this withGraham's >> proposal for adding cleanup handlers...) > > class MyApplication(object): >   def __init__(self): >       pass # proce

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

On 2011-01-08 09:00:18 -0800, P.J. Eby said: (The next interesting challenge would be to integrate this withGraham's proposal for adding cleanup handlers...) class MyApplication(object): def __init__(self): pass # process startup code def __call__(self, environ): yield Non

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

At 01:24 PM 1/8/2011 -0500, Paul Davis wrote: For contrast, I thought it might be beneficial to have a comparison with an implementation that didn't use async might look like: http://friendpaste.com/4lFbZsTpPGA9N9niyOt9PF Compare your version with this one, that uses my revision of Alice's pro

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

On Sat, Jan 8, 2011 at 6:26 AM, Alice Bevan–McGregor wrote: > Warning: this assumes we're running on bizzaro-world PEP 444 that mandates > applications are generators.  Please do not dismiss this idea out of hand > but give it a good look and maybe some feedback.  ;) > > -- > > Howdy! > > I've fin

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

At 05:39 AM 1/8/2011 -0800, Alice Bevan­McGregor wrote: As a quick note, this proposal would signifigantly benefit from the simplified syntax offered by PEP 380 (Syntax for Delegating to a Subgenerator) [1] and possibly PEP 3152 (Cofunctions) [2]. The former simplifies delegation and exception

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

I made a few errors in that massive post... At 12:00 PM 1/8/2011 -0500, P.J. Eby wrote: My major concern about the approach is still that it requires a fair amount of overhead on the part of both app developers and middleware developers, even if that overhead mostly consists of importing and d

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

At 03:26 AM 1/8/2011 -0800, Alice Bevan­McGregor wrote: Warning: this assumes we're running on bizzaro-world PEP 444 that mandates applications are generators. Please do not dismiss this idea out of hand but give it a good look and maybe some feedback. ;) First-glance feedback: I'm impressed

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

On 2011-01-07 09:47:12 -0800, Timothy Farrell said: However, I'm requesting that servers _optionally_ provide environ['wsgi.executor'] as a futures executor that applications can use for the purpose of doing something after the response is fully sent to the client. This is feature request is

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

On 2011-01-08 06:08:57 -0800, David Stanek said: Under the new spec would I be forced to make my applications and middleware this complicated? An application that does not utilize futures (and thus this proposal for async) is different from the current draft as it is written [1] by only one w

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

On Sat, Jan 8, 2011 at 6:26 AM, Alice Bevan–McGregor wrote: > > I've finished touching up the p-code illustrating my idea of using > generators to implement async functionality within a WSGI application and > middleware, including the idea of a wsgi2ref-supplied decorator to simplify > middleware.

Re: [Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

As a quick note, this proposal would signifigantly benefit from the simplified syntax offered by PEP 380 (Syntax for Delegating to a Subgenerator) [1] and possibly PEP 3152 (Cofunctions) [2]. The former simplifies delegation and exception passing, and the latter simplifies the async side of th

[Web-SIG] [PEP 444] Future- and Generator-Based Async Idea

Warning: this assumes we're running on bizzaro-world PEP 444 that mandates applications are generators. Please do not dismiss this idea out of hand but give it a good look and maybe some feedback. ;) -- Howdy! I've finished touching up the p-code illustrating my idea of using generators to

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

On 2011-01-07 16:39:46 -0800, Alex Grönholm said: I believe allowing wsgi.executor to be either a process pool or a thread pool is a recipe for disaster. I'm really not sure where to go from here. Two solutions: :: Don't pass an executor to the job such that it can not schedule its own futur

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

On 2011-01-07 13:21:36 -0800, Antoine Pitrou said: Ok, so, WSGI doesn't "already involve generators". QED. Let me try this again. With the understanding that: :: PEP 333[3] and 444 define a response body as an iterable. :: Thus WSGI involves iterables through definition. :: A generator is a t

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

On 2011-01-07 22:13:17 -0800, Alex Grönholm said: 08.01.2011 07:09, P.J. Eby wrote: On the plus side, the "run this in a future after the request" concept has some legs... [snip] What exactly does "run this in a future after the request" mean? There seems to be some terminology confusion here

Re: [Web-SIG] PEP 444 Goals

On 2011-01-07 20:34:09 -0800, P.J. Eby said: That it [handling generators] is difficult at all means removes degree-of-difficulty as a strong motivation to switch. Agreed. I will be following up with a more concrete idea (including p-code) to better describe what is currently in my brain. (O

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

08.01.2011 07:09, P.J. Eby kirjoitti: At 12:37 PM 1/7/2011 -0800, Alice Bevan­McGregor wrote: But is there really any problem with providing a unified method for indication a suspend point? Yes: a complexity burden that is paid by the many to serve the few -- or possibly non-existent. I sti

Re: [Web-SIG] PEP 444 Goals

At 01:22 PM 1/7/2011 -0800, Alice Bevan­McGregor wrote: On 2011-01-07 08:28:15 -0800, P.J. Eby said: At 01:17 AM 1/7/2011 -0800, Alice Bevan­McGregor wrote: On 2011-01-06 20:18:12 -0800, P.J. Eby said: :: Reduction of re-implementation / NIH syndrome by>>>incorporating>the most common (1%) of

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

At 12:37 PM 1/7/2011 -0800, Alice Bevan­McGregor wrote: But is there really any problem with providing a unified method for indication a suspend point? Yes: a complexity burden that is paid by the many to serve the few -- or possibly non-existent. I still haven't seen anything that suggests

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

08.01.2011 05:36, Antoine Pitrou kirjoitti: Alice Bevan–McGregor writes: On 2011-01-07 13:21:36 -0800, Antoine Pitrou said: Ok, so, WSGI doesn't "already involve generators". QED. This can go around in circles; by allowing all forms of iterable, it involves generators. Geneators are a type o

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

Alice Bevan–McGregor writes: > > On 2011-01-07 13:21:36 -0800, Antoine Pitrou said: > > Ok, so, WSGI doesn't "already involve generators". QED. > > This can go around in circles; by allowing all forms of iterable, it > involves generators. Geneators are a type of iterable. QED right > back.

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

07.01.2011 19:59, Guido van Rossum kirjoitti: If it's optional, what's the benefit for the app of getting it through WSGI instead of through importing some other standard module? The API of the executor will require a lot of thought. I worry that this weighs down the WSGI standard with the respon

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

07.01.2011 07:24, Alex Grönholm kirjoitti: 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 t

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

On 2011-01-07 09:04:07 -0800, Antoine Pitrou said: WSGI doesn't mandate any specific feature of generators, such as coroutine-like semantics, and the server doesn't have to know about them. The joy of writing a new specification is that we are not (potentially) shackled by old ways of doing t

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

On 2011-01-07 13:21:36 -0800, Antoine Pitrou said: Ok, so, WSGI doesn't "already involve generators". QED. This can go around in circles; by allowing all forms of iterable, it involves generators. Geneators are a type of iterable. QED right back. ;) Right, that's why I was suggesting you

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

On 2011-01-07 12:42:24 -0800, Paul Davis said: Is the code for this server online? I'd be interested in reading through it. https://github.com/pulp/marrow.server.http There are two branches: master will always refer to the version published on Python.org, and draft refers to my rewrite. (Wh

Re: [Web-SIG] PEP 444 Goals

On 2011-01-07 08:28:15 -0800, P.J. Eby said: At 01:17 AM 1/7/2011 -0800, Alice Bevan­McGregor wrote: On 2011-01-06 20:18:12 -0800, P.J. Eby said: :: Reduction of re-implementation / NIH syndrome by>>>incorporating>the most common (1%) of features most often>>>relegated to middleware>or functio

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

Alice Bevan–McGregor writes: > > On 2011-01-07 09:04:07 -0800, Antoine Pitrou said: > > Alice Bevan–McGregor writes: > >>> I don't understand why you want a "yield" at this level. IMHO, WSGI > >>> needn't involve generators. A higher-level wrapper (framework, > >>> middleware, whatever) can wr

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

- 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 > This seems like a potentially good way to do it; I suggest making it

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

> There is practically no reason for doing so; esp. considering that I've > managed to write a 2k/3k polygot server that is more performant out of the > box than any other WSGI HTTP server I've come across and is far simpler in > implementation than most of the ones I've come across with roughly >

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

On 2011-01-07 08:10:43 -0800, P.J. Eby said: At 12:39 AM 1/7/2011 -0800, Alice Bevan­McGregor wrote: :: Image scaling would benefit from multi-processing (spreading the>load across cores). Also, only one sacle is immediately required>before returning the post-upload page: the thumbnail. The o

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

On 2011-01-07 09:04:07 -0800, Antoine Pitrou said: Alice Bevan–McGregor writes: I don't understand why you want a "yield" at this level. IMHO, WSGI needn't involve generators. A higher-level wrapper (framework, middleware, whatever) can wrap fd-waiting in fancy generator stuff if so desired.

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

On Fri, Jan 7, 2011 at 9:47 AM, Timothy Farrell wrote: There has been much discussion about how to handle async in PEP 444 and that discussion centers around the use of futures.  However, I'm requesting that servers _optionally_ provide environ['wsgi.executor'] as a futures executor that applic

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

At 11:47 AM 1/7/2011 -0600, Timothy Farrell wrote: There has been much discussion about how to handle async in PEP 444 and that discussion centers around the use of futures. However, I'm requesting that servers _optionally_ provide environ['wsgi.executor'] as a futures executor that applicatio

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

ht need changing? Granted, it would not be ideal if an application called executor.shutdown(). This doesn't seem difficult to my tiny brain. - Original Message - From: "Guido van Rossum" To: "Timothy Farrell" Cc: web-sig@python.org Sent: Friday, Januar

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

If it's optional, what's the benefit for the app of getting it through WSGI instead of through importing some other standard module? The API of the executor will require a lot of thought. I worry that this weighs down the WSGI standard with the responsibility of coming up with the perfect executor

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

There has been much discussion about how to handle async in PEP 444 and that discussion centers around the use of futures. However, I'm requesting that servers _optionally_ provide environ['wsgi.executor'] as a futures executor that applications can use for the purpose of doing something after

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

;P.J. Eby" Cc: al...@gothcandy.com, web-sig@python.org Sent: Thursday, January 6, 2011 11:30:11 PM Subject: 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

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

Alice Bevan–McGregor writes: > > > I don't understand why you want a "yield" at this level. IMHO, WSGI > > needn't involve generators. A higher-level wrapper (framework, > > middleware, whatever) can wrap fd-waiting in fancy generator stuff if > > so desired. Or, in some other environments, de

Re: [Web-SIG] PEP 444 Goals

> No, otherwise I'd totally go for the surrogateescape approach. Heck, > I'd still go for it if it were possible to write a surrogateescape > handler for 2.6, and require that a PEP 444 server register one with > Python's codec system. I don't know if it's *possible*, though, > hopefully some

Re: [Web-SIG] PEP 444 Goals

At 01:17 AM 1/7/2011 -0800, Alice Bevan­McGregor wrote: On 2011-01-06 20:18:12 -0800, P.J. Eby said: :: Reduction of re-implementation / NIH syndrome by incorporating>the most common (1%) of features most often relegated to middleware>or functional helpers. Note that nearly every application-fr

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

At 12:39 AM 1/7/2011 -0800, Alice Bevan­McGregor wrote: Earlier in this post I illustrated a few that directly apply to a commercial application I am currently writing. I'll elaborate: :: Image scaling would benefit from multi-processing (spreading the load across cores). Also, only one sacle

Re: [Web-SIG] PEP 444 Goals

On 2011-01-07 01:08:42 -0800, chris.dent said: ... this particular goal [reduction of reimplementation / NIH] could cover a large number of things from standardized query string processing (maybe a good idea) to filters (which I've already expressed reservations about). So this goal seems lik

Re: [Web-SIG] PEP 444 Goals

On 2011-01-06 20:18:12 -0800, P.J. Eby said: :: Reduction of re-implementation / NIH syndrome by incorporating>the most common (1%) of features most often relegated to middleware>or functional helpers. Note that nearly every application-friendly feature you add will increase the burden on bot

Re: [Web-SIG] PEP 444 Goals

On Thu, 6 Jan 2011, Alice Bevan–McGregor wrote: :: 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". +1 :: Isolation of examples and rationale to improve readability of the co

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

On 2011-01-06 10:15:19 -0800, Antoine Pitrou said: 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 t

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

On 2011-01-06 20:49:57 -0800, P.J. Eby said: It would be helpful if you addressed the issue of scope, i.e., whatfeatures are you proposing to offer to the application developer. Conformity, predictability, and portability. That's a lot of y's. (Pardon the pun!) Alex Grönholm's post describ

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] 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] 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

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" (

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

Alex Grönholm and I have been discussing async implementation details (and other areas of PEP 444) for some time on IRC. Below is the cleaned up log transcriptions with additional notes where needed. Note: The logs are in mixed chronological order — discussion of one topic is chronological, p

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

[Apologies if this is a double- or triple-post; I seem to be having a stupid number of connectivity problems today.] Howdy! Apologies for the delay in responding, it’s been a hectic start to the new year.  :) On 2011-01-03, at 6:22 AM, Timothy Farrell wrote: You don't know me but I'm the au

Re: [Web-SIG] PEP 444 != WSGI 2.0

On Sun, Jan 2, 2011 at 7:08 PM, Tres Seaver wrote: > On 01/02/2011 04:31 PM, Guido van Rossum wrote: >> On Sun, Jan 2, 2011 at 12:55 PM, Masklinn wrote: >> >>> On 2011-01-02, at 21:38 , Alice Bevan–McGregor wrote: On 2011-01-02 11:14:00 -0800, Chris McDonough said: >> I'd suggest we just

Re: [Web-SIG] PEP 444 != WSGI 2.0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/02/2011 04:31 PM, Guido van Rossum wrote: > On Sun, Jan 2, 2011 at 12:55 PM, Masklinn wrote: > >> On 2011-01-02, at 21:38 , Alice Bevan–McGregor wrote: >>> On 2011-01-02 11:14:00 -0800, Chris McDonough said: > I'd suggest we just embrace it

Re: [Web-SIG] PEP 444 != WSGI 2.0

At 02:21 PM 1/2/2011 -0800, Alice Bevan­McGregor wrote: On 2011-01-02 11:57:19 -0800, P.J. Eby said: * -1 on the key-specific encoding schemes for the various CGI variables' values -- for continuity of coding (not to mention simplicity) PEP 's approach to environ encodings should beused. (T

Re: [Web-SIG] PEP 444 != WSGI 2.0

At 12:38 PM 1/2/2011 -0800, Alice Bevan­McGregor wrote: On 2011-01-02 11:14:00 -0800, Chris McDonough said: I'd suggest we just embrace it, adding minor tweaks as necessary, until we reach some sort of technical impasse it doesn't address. Async is one area that does not cover, and that b

Re: [Web-SIG] PEP 444 != WSGI 2.0

On 2011-01-02, at 23:16 , Alice Bevan–McGregor wrote: >> (Just trying to keep this thread from degenerating into a shouting match.) > I missed how his statements could be construed as offensive. :/ I missed it as well (though my report might have been brusque), and definitely didn't intent it to

  1   2   3   >