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
On 2011-01-06 10:15:19 -0800, Antoine Pitrou said:
Alice Bevan–McGregor al...@... 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
At 12:39 AM 1/7/2011 -0800, Alice BevanMcGregor 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
Alice Bevan–McGregor al...@... 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,
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 p...@telecommunity.com wrote:
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Tossing the idea around all day
On 2011-01-07 09:04:07 -0800, Antoine Pitrou said:
Alice Bevan–McGregor al...@... 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
On 2011-01-07 08:10:43 -0800, P.J. Eby said:
At 12:39 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
:: Image scaling would benefit from multi-processing (spreading
theload across cores). Also, only one sacle is immediately
requiredbefore returning the post-upload page: the thumbnail. The
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
Alice Bevan–McGregor al...@... writes:
On 2011-01-07 09:04:07 -0800, Antoine Pitrou said:
Alice Bevan–McGregor al...@... 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
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.
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
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
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 BevanMcGregor wrote:
Tossing the idea around all day long will then, of course, be
happening regardless. Unfortunately for that particular discussion,
PEP 3148 / Futures seems
Alice Bevan–McGregor al...@... 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.
08.01.2011 05:36, Antoine Pitrou kirjoitti:
Alice Bevan–McGregoral...@... 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
At 12:37 PM 1/7/2011 -0800, Alice BevanMcGregor 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
08.01.2011 07:09, P.J. Eby kirjoitti:
At 12:37 PM 1/7/2011 -0800, Alice BevanMcGregor 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
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.
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
Alice Bevan–McGregor al...@... 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
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
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
On 2011-01-06 03:53:14 -0800, Antoine Pitrou said:
Alice Bevan-McGregor al...@... 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
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 added
At Thu, 6 Jan 2011 13:03:15 + (GMT),
chris dent wrote:
snip
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.
/snip
+1
After
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
06.01.2011 20:02, Eric Larson kirjoitti:
At Thu, 6 Jan 2011 13:03:15 + (GMT),
chris dent wrote:
snip
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
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 WSGI
2011/1/6 Alex Grönholm alex.gronh...@nextday.fi
06.01.2011 20:02, Eric Larson kirjoitti:
At Thu, 6 Jan 2011 13:03:15 + (GMT),
chris dent wrote:
snip
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
06.01.2011 23:11, Sylvain Hellegouarch kirjoitti:
2011/1/6 Alex Grönholm alex.gronh...@nextday.fi
mailto:alex.gronh...@nextday.fi
06.01.2011 20:02, Eric Larson kirjoitti:
At Thu, 6 Jan 2011 13:03:15 + (GMT),
chris dent wrote:
snip
On async:
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor 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
07.01.2011 06:49, P.J. Eby kirjoitti:
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor 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
On Thu, Jan 6, 2011 at 8:49 PM, P.J. Eby p...@telecommunity.com wrote:
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor 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
[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
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,
35 matches
Mail list logo
