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
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
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
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.1
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
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
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 clarifications
On 2011-01-06 13:08:04 -0800, Robert Brewer said:
Or, if you had actually read what I wrote weeks ago...
I did. Apologies for forgetting the detail of the implementation being
deprecated.
We don't need Yet Another Way of hooking in processing components; if
anything, we need a standard
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
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:
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,
2011/1/7 Alex Grönholm alex.gronh...@nextday.fi:
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
2011/1/7 Graham Dumpleton graham.dumple...@gmail.com:
2011/1/7 Alex Grönholm alex.gronh...@nextday.fi:
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
07.01.2011 04:09, Graham Dumpleton kirjoitti:
2011/1/7 Graham Dumpletongraham.dumple...@gmail.com:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
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
2011/1/7 Alex Grönholm alex.gronh...@nextday.fi:
07.01.2011 04:09, Graham Dumpleton kirjoitti:
2011/1/7 Graham Dumpletongraham.dumple...@gmail.com:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One other comment about HTTP/1.1 features.
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 has
2011/1/7 James Y Knight f...@fuhm.net:
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
07.01.2011 04:55, Graham Dumpleton kirjoitti:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 04:09, Graham Dumpleton kirjoitti:
2011/1/7 Graham Dumpletongraham.dumple...@gmail.com:
2011/1/7 Alex Grönholmalex.gronh...@nextday.fi:
07.01.2011 01:14, Graham Dumpleton kirjoitti:
One
At 12:52 PM 1/6/2011 -0800, Alice BevanMcGregor 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.
::
At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
Is that the last thing or do I need to go spend some time and write my
own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
lying around and just do some final validation checks with a parallel
implementation as a sanity check
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
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:
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 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. (Honestly not
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
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
On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote:
At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
Is that the last thing or do I need to go spend some time and write my
own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
lying around and just do some final validation checks
On Thu, Jan 6, 2011 at 9:47 PM, James Y Knight f...@fuhm.net wrote:
On Jan 6, 2011, at 11:30 PM, P.J. Eby wrote:
At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
Is that the last thing or do I need to go spend some time and write my
own CGI/WSGI bridge for Python 3 based on my own Python 2
Stupid question first. When running 2to3 on the example CGI code, why
would it throw back the following. Is this indicative of anything else
that needs to be changed to satisfy some Python 3 thing. The list()
bit seems redundant, but I don't know what the other stuff is about.
--- xx.py
The version at:
http://svn.python.org/projects/peps/trunk/pep-.txt
still shows:
elif not headers_sent:
# Before the first output, send the stored headers
status, response_headers = headers_sent[:] = headers_set
sys.stdout.write('Status: %s\r\n'
On 2011-01-06 22:00:17 -0800, Graham Dumpleton said:
-environ = {k: wsgi_string(v) for k,v in os.environ.items()}
+environ = {k: wsgi_string(v) for k,v in list(os.environ.items())}
2to3 takes the conservative route of assuming your application treats
dict.items() as a list in all
On 7 January 2011 17:22, Graham Dumpleton graham.dumple...@gmail.com wrote:
On 7 January 2011 17:13, Graham Dumpleton graham.dumple...@gmail.com wrote:
The version at:
http://svn.python.org/projects/peps/trunk/pep-.txt
still shows:
elif not headers_sent:
# Before
On 7 January 2011 17:19, Alice Bevan–McGregor al...@gothcandy.com wrote:
- raise exc_info[0], exc_info[1], exc_info[2]
+ raise
exc_info[0](exc_info[1]).with_traceback(exc_info[2])
The exception raising syntax has changed; you can not re-raise an exception
On 7 January 2011 18:23, Alice Bevan–McGregor al...@gothcandy.com wrote:
On 2011-01-06 21:35:24 -0800, Jacob Kaplan-Moss said:
Other than mod_wsgi, are there any PEP -compliant (or near-compliant)
components in the wild? Enough to bring a framework to life in Python 3?
What I see is the
On 2011-01-06 23:40:53 -0800, Graham Dumpleton said:
There is also uWSGI and CherryPy WSGI server. I recollect that Benoit
may have started looking it over for gunicorn.
Ah, right, I recall seeing CherryPy mentioned in archived discussions.
So there's hope, then, for relatively quick
42 matches
Mail list logo
