At 01:09 PM 4/1/2009 -0700, Guido van Rossum wrote:
Well you could make the bytes versions available under different keys.
I think you do something a bit similar this in webob, e.g. req.params
vs. req.str_params. (Perhaps you could have QUERY_STRING and
QUERY_BYTES.) The decode() call used to
At 10:11 AM 4/2/2009 +1100, Graham Dumpleton wrote:
Seems to me that you can't have it be configurable and it must always
be latin-1 interpretation. The problem is where you are composing
multiple WSGI applications. If they each have different expectations
or requirements as to how it is
At 08:07 AM 5/8/2009 -0700, Robert Brewer wrote:
I decided that that single type should be byte strings because I want
WSGI middleware and applications to be able to choose what encoding
their output is. Passing unicode to the server would require some
out-of-band method of telling the server
At 10:37 AM 5/8/2009 -0700, Robert Brewer wrote:
It also explicitly states that HTTP does not directly support Unicode,
and neither does this interface. All encoding/decoding must be handled
by the application; all strings passed to or from the server must be
standard Python BYTE STRINGS
At 02:39 PM 5/8/2009 -0400, James Y Knight wrote:
On May 8, 2009, at 1:37 PM, Robert Brewer wrote:
If Python3 WSGI apps emit unicode strings (py3k type 'str'), you're
effectively saying the server will always call
chunk.encode('latin-1'). That negates any benefit of using unicode
as
the type
At 06:05 PM 5/8/2009 -0400, James Y Knight wrote:
On May 8, 2009, at 6:00 PM, P.J. Eby wrote:
Compatibility sometimes demands we do silly things. Personally, I
think it's kind of silly that Python 3 files return incompatible
data types depending on what mode you open them in, but there's
At 05:19 PM 6/16/2009 +0200, Martijn Faassen wrote:
Hey,
On Tue, Jun 16, 2009 at 4:51 PM, Etienne
Robillardrobillard.etie...@gmail.com wrote:
Nothing very new here. At least next time try to be a little more
creative, otherwise this is getting slightly boring and repetitive...
It's a bit
At 04:32 PM 8/3/2009 -0500, Ian Bicking wrote:
Would this be a new PEP or a revision? I think it should be a new
PEP, as WSGI 1 remains valid and the same as it always was, and PEP
333 describes that.
+1 for a new PEP, since we'd be able to drop a lot of crufty examples
and explanations
At 10:48 AM 8/4/2009 +1000, Graham Dumpleton wrote:
2009/8/4 P.J. Eby p...@telecommunity.com:
At 04:32 PM 8/3/2009 -0500, Ian Bicking wrote:
Would this be a new PEP or a revision? I think it should be a new
PEP, as WSGI 1 remains valid and the same as it always was, and PEP
333 describes
At 10:38 AM 8/4/2009 +1000, Graham Dumpleton wrote:
1. When running under Python 3, applications SHOULD produce bytes
output, status line and headers.
This is effectively what we had before. The only difference is that
clarify that the 'status line' values should also be bytes. This
wasn't
At 02:28 PM 8/4/2009 +1000, Graham Dumpleton wrote:
2009/8/4 P.J. Eby p...@telecommunity.com:
I'm not clear on your logic here. If I request foo/bar/baz (where baz
actually has an accent over the 'a') in latin-1 encoding, and
foo/bar is the
script, then the (accented) baz is legitimate
At 10:44 PM 8/4/2009 +1000, Graham Dumpleton wrote:
In summary, what are the practical uses cases that would make passing
bytes over UTF-8 or even latin-1 worthwhile?
My concern at this point is a nagging feeling that we are abandoning
WSGI-HTTP equivalence for convenience in the face of
At 10:53 AM 8/5/2009 +1000, Graham Dumpleton wrote:
Now, the main reason why I am throwing around alternate suggestions in
the first place is that last time although people seem to be
comfortable moving along with the idea of latin-1 everywhere, I knew
of some who weren't happy with that, some
At 07:37 AM 8/17/2009 -0700, Robert Brewer wrote:
Did I say 3 reasons? I meant 4: Accept-Charset.
Chief amongst the reasons... amongst our reasonry... Right, we'll
come in again. ;-)
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG:
On his blog, Graham mentioned some skepticism about skipping WSGI 1.1
and going straight to 2.0, due to concern that people using write()
would need to make major code changes to go to WSGI 2.0.
Now, if we ignore the part of the spec that says New WSGI
applications and frameworks *should not*
At 06:58 PM 9/18/2009 -0500, Ian Bicking wrote:
What's wrong with this simpler approach to the conversion?
It's not compliant with the WSGI 1 spec, which calls for write() to
be unbuffered.
On the one hand, you could say that anybody who gives a crap about
the spec wouldn't use write() to
At 02:08 AM 9/19/2009 +0200, Armin Ronacher wrote:
greenlets are one solution, but I don't think there are any applications
out there using write() that are worth supporting in WSGI 2.0. Such
applications should rather use an internal buffer and write to that.
If an internal buffer was
At 08:06 PM 9/18/2009 +1000, Graham Dumpleton wrote:
Sometimes clients calling the wsgi code will be
buggy... and looking at the unquoted url is needed in those cases to
work around buggy clients.
Bugs in WSGI adapters aren't a good reason for why it is needed. If
the WSGI adapters are
At 03:06 PM 9/20/2009 +0200, Armin Ronacher wrote:
Hello everybody,
Thanks to Graham Dumpleton and Robert Brewer there is some serious
progress on WSGI currently. I proposed a roadmap with some PEP changes
now that need some input.
Summary:
WSGI 1.0 stays the same as PEP 0333
At 08:48 AM 9/20/2009 -0400, Etienne Robillard wrote:
Good plan but I'm afraid now only a bunch of elite people on this list
is going to remember all the details on theses upcoming
specifications. Why the rush to specify WSGI 3.0 and not focus
mainly on the next one ahead ?
Because having more
At 04:50 PM 9/20/2009 +0200, Armin Ronacher wrote:
Django, Pylons, SQLAlchemy, Mako, Jinja2, Genshi, Werkzeug, WebOb and
many more technologies are based on unicode, even in Python 2.x. They
are currently doing decoding of byte data internally.
In Python 2.x if we stick to native strings for
At 04:30 PM 9/21/2009 +0100, René Dudfield wrote:
On Mon, Sep 21, 2009 at 4:19 PM, P.J. Eby p...@telecommunity.com wrote:
At 12:25 AM 9/21/2009 -0400, Chris McDonough wrote:
Anyway, for us slower (and maybe wrongly fearful) folks, could someone
summarize the benefits of having a WSGI
At 11:23 AM 9/21/2009 -0700, Robert Brewer wrote:
I still don't see why the environ should have multiple versions of
anything. It's not as if the HTTP request gives us multiple
Request-URI's. There's a single processing step that has to happen
somewhere: decoding the bytes of the Request-URI
At 01:15 PM 9/21/2009 -0700, Robert Brewer wrote:
I don't understand. If SCRIPT_NAME/PATH_INFO/QUERY_STRING are
unicode, the only answer to what's been done to the URI? can be
wsgi.uri_encoding, which allows someone to un-do it. What more do you want?
To be sure that there's no possible way
At 03:26 PM 9/21/2009 -0700, Robert Brewer wrote:
It looks simpler until you have a site that is not primarily utf-8. In
that case, you multiply your (1 line * number of middlewares in the WSGI
stack * each request). With wsgi.uri_encoding you get either (1 line * 1
middleware designed to
At 07:40 PM 9/21/2009 -0700, Robert Brewer wrote:
Yes; you have to transcode to the correct encoding. Once. Then every
other WSGI application interface below that one doesn't have to care.
You can only do that if you *break encapsulation*, which as I said
earlier is voiding the entire point
At 07:21 PM 9/21/2009 -0700, Robert Brewer wrote:
I've never proposed that WSGI make choices for people. I'm simply
saying that a configurable server, with a sane, perfectly-reversible
default, is the simplest thing that could possibly work.
Actually, latin-1 bytes encoding is the *simplest*
At 02:30 PM 9/22/2009 +1000, Graham Dumpleton wrote:
Someone did say something about being able to half make it work on
Python 2.X. Can someone properly provide example code for Python 2.X.
The issue is that error handlers on encode are only allowed to
provide substitute unicode characters,
At 04:44 PM 9/22/2009 +1000, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham m...@mnot.net:
That blog entry is eleven printed pages. Given that PEP 333 also prints as
eleven pages from my browser, I suspect there's some extraneous information
in there.
Could you please summarise?
At 09:23 AM 9/22/2009 +0100, Alan Kennedy wrote:
[P.J. Eby]
Actually, latin-1 bytes encoding is the *simplest* thing that could
possibly work, since it works already in e.g. Jython, and is actually
in the spec already... and any framework that wants unicode URIs
already has to decode them
At 11:28 AM 9/22/2009 +0200, Armin Ronacher wrote:
Hi,
Alan Kennedy schrieb:
2. Give the programmer (possibly mojibake) unicode strings in the WSGI
environ anyway
3. And let them solve their problems themselves, using server
configuration or bespoke middleware
Because that problem was
At 11:30 AM 9/22/2009 +0100, Alan Kennedy wrote:
I see this as being the same as Graham's suggested approach of a
per-server configurable charset, which is then stored in the WSGI
dictionary, so that applications that have problems, i.e. that detect
mojibake in the unicode SCRIPT_NAME or
At 03:22 PM 9/22/2009 +0100, René Dudfield wrote:
On Tue, Sep 22, 2009 at 3:07 PM, P.J. Eby p...@telecommunity.com wrote:
At 11:30 AM 9/22/2009 +0100, Alan Kennedy wrote:
I see this as being the same as Graham's suggested approach of a
per-server configurable charset, which is then stored
At 05:12 PM 9/22/2009 -0700, Philip Jenvey wrote:
Because our request container is a plain, pre-fabricated dict that
doesn't permit the lazy behavior.
Not quite true; you can always write a library function,
get_foo(environ) that does the lazy caching in a private environ key,
at the cost of
At 02:43 PM 9/23/2009 +1000, Graham Dumpleton wrote:
Sorry, after having had a bit of think while eating lunch, I am going
to throw up another point of view on this whole issue. So, sit back
and be just a little bit concerned.
WSGI stands for Web Server GATEWAY Interface.
My understanding is
At 08:42 AM 9/23/2009 +0200, Armin Ronacher wrote:
I then propose that we eliminate SCRIPT_NAME and PATH_INFO. Instead we
have:
IMO they should stick around for compatibility with older applications
and be latin1 encoded on Python 3. But the use is discouraged.
One or the other should be
At 11:47 AM 9/24/2009 +1000, Graham Dumpleton wrote:
After almost two years of trying to get WSGI for Python 3.0 to fly, I really
do think it is time for me to give up. I did say a while back I would
try one last push and this has been it.
I'm sorry you feel that way, and I'm sorry if I
At 08:42 PM 11/26/2009 -0500, James Y Knight wrote:
I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the
official definition of WSGI 1.1, which describes how to implement
WSGI adapters for both Python 2.x and 3.x. It may not be perfect,
but, it's been implemented twice, and seems ot
At 12:34 PM 11/27/2009 -0500, James Y Knight wrote:
On Nov 27, 2009, at 10:20 AM, P.J. Eby wrote:
Second, I do not think that the additional
guarantees/requirements can be safely added to a 1.x version, as
they make it impossible for an app to tell whether it's *really*
running under 1.1
At 08:42 AM 1/4/2010 -0800, Aaron Watters wrote:
From: Aaron Watters arw1...@yahoo.com
If an application returns an iterable response and *also*
calls the write()... what is supposed to happen?
After carefully considering all the responses on this issue ;c)
I came up with the
At 04:08 PM 4/8/2010 +0200, Manlio Perillo wrote:
Hi.
Some time ago I objected the decision to remove start_response function
from next version WSGI, using as rationale the fact that without
start_callable, asynchronous extension are impossible to support.
Now I have found that removing
At 04:59 PM 4/8/2010 +0200, Manlio Perillo wrote:
Aaron Watters ha scritto:
someone remind me: where is the canonical WSGI 2 spec?
http://wsgi.org/wsgi/WSGI_2.0
I assume there is a way to wrap WSGI 1 applications
without breaking them? Or is this the regex--re fiasco
all over again?
At 08:06 PM 4/8/2010 +0200, Manlio Perillo wrote:
What I'm trying to do is:
* as in the example I posted, turn Mako render function in a generator.
The reason is that I would lite to to implement support for Nginx
subrequests.
By subrequest, do you mean that one request is invoking
At 01:25 PM 4/12/2010 +0200, Manlio Perillo wrote:
The purpose of the extension if to just have a standard interface that
WSGI applications can use to take advantage of the possibility, offered
by asynchronous server, to suspend execution and resume it later.
WSGI has this ability now - it's
At 01:01 PM 6/28/2010 -0600, Aaron Fransen wrote:
One of the nice things about mod_python is the req.write() function.
Although I realize it's somewhat of an abuse to the http protocol,
it's handy being able to periodically update the client browser with
a status message for a long-running
At 03:43 PM 6/28/2010 -0600, Aaron Fransen wrote:
Using mod_wsgi on Apache doesn't seem to exhibit that behavior.
You may need WSGIOutputBuffering Off in your config; see:
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIOutputBuffering
Another possibility is that you've got
At 10:14 AM 6/29/2010 -0600, Aaron Fransen wrote:
Couple more things I've been able to discern.
The first happened after I fixed the html code. Originally under
mod_python, I guess I was cheating more than a little bit by sending
html/html code blocks twice, once for the incremental notices,
At 12:33 PM 6/29/2010 -0600, Aaron Fransen wrote:
I was sending text/html (I probably should have used multipart
before) ... should I try multipart now, even with having everything
in a single stream?
Heck if I know. I just assumed that what you're doing would be
unlikely to work, whereas
At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
And this doesn't help with Python 3: either we have byte values of
SCRIPT_NAME and PATH_INFO in Python 3, or we have text values. I
think bytes will be more awkward to port to than text, and
inconsistent with other WSGI values.
OTOH, it has
At 02:28 PM 7/16/2010 -0500, Ian Bicking wrote:
On Fri, Jul 16, 2010 at 1:40 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
And this doesn't help with Python 3: either we have byte values of
SCRIPT_NAME and PATH_INFO
At 05:42 PM 7/16/2010 -0400, Tres Seaver wrote:
P.J. Eby wrote:
(Hm. Although actually, I suppose we *could* just borrow the time
machine and pretend that WSGI called for byte-strings everywhere
all along...)
I like the idea of pushing responsibility for decoding stuff into the
framework
At 01:01 PM 7/18/2010 +1000, Graham Dumpleton wrote:
This is on the basis that if people are going to have to rewrite their code
a fair bit to handle bytes everywhere,
What you mean by rewrite their code a fair bit, and who is it that
you think will have to do this?
Or, more precisely, how
At 06:05 PM 8/27/2010 +0200, Christoph Zwerschke wrote:
For instance,
user = 'özkan'.encode('latin1')
if user in request.META.get('REMOTE_USER', b'').lower():
will not work it the user has logged in as 'Özkan'.
Isn't that a problem with code that does this now?
At 02:37 PM 8/30/2010 +1000, Graham Dumpleton wrote:
Anyway, rather than keep arguing the point and move forward, let us
perhaps start now with the following definitions and new names to
identify them. We can even go a bit stupid and give each its own code
name so they are in part more
At 07:03 PM 9/15/2010 -0400, Chris McDonough wrote:
A PEP was submitted and accepted today for a WSGI successor protocol
named Web3:
http://python.org/dev/peps/pep-0444/
I'd encourage other folks to suggest improvements to that spec or to
submit a competing spec, so we can get WSGI-on-Python3
At 10:35 AM 9/16/2010 -0700, Guido van Rossum wrote:
No comments on the rest except to note that at this point it looks
unlikely that we can make everyone happy (or even get an agreement to
adopt what would be the long-term technically optimal solution --
AFAICT there is no agreement on what
At 02:17 PM 9/16/2010 -0500, Ian Bicking wrote:
On Thu, Sep 16, 2010 at 1:04 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
* Clarifying the encoding of environ values (locale+surrogateescape
vs. latin1, TBD)
locale+surrageescape would be insanity! CGI will just
At 03:43 PM 9/17/2010 +0200, And Clover wrote:
On 09/17/2010 02:03 PM, Armin Ronacher wrote:
In case we change the spec as Ian mentioned above, I am all for
a wsgi.guessed_encoding = True flag or something like that.
Yes, I'd like to see that. I believe going with *only* a
At 09:01 AM 9/18/2010 -0700, Robert Brewer wrote:
Marcel Hellkamp wrote:
Removing any support for this type of asynchronism would render web3
useless for all but completely synchronous and trivial applications.
Even frameworks would have no way to work around this anymore.
I've run a few
While the Web-SIG is trying to hash out PEP 444, I thought it would
be a good idea to have a backup plan that would allow the Python 3
stdlib to move forward, without needing a major new spec to settle
out implementation questions.
After all, even if PEP 333 is ultimately replaced by PEP 444,
At 12:55 PM 9/21/2010 -0400, Ian Bicking wrote:
On Tue, Sep 21, 2010 at 12:47 PM, Chris McDonough
mailto:chr...@plope.comchr...@plope.com wrote:
On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote:
While the Web-SIG is trying to hash out PEP 444, I thought it would
be a good idea to have
At 06:52 PM 9/21/2010 +0200, Antoine Pitrou wrote:
On Tue, 21 Sep 2010 12:09:44 -0400
P.J. Eby p...@telecommunity.com wrote:
While the Web-SIG is trying to hash out PEP 444, I thought it would
be a good idea to have a backup plan that would allow the Python 3
stdlib to move forward, without
[trimming reply headers to just web-sig]
At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote:
On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
The Python 3 specific changes are to use:
* ``bytes`` for I/O streams in both directions
* ``str
At 08:34 AM 9/22/2010 -0700, Robert Brewer wrote:
Marcel Hellkamp wrote:
I would like to add a warning to the WSGI/web3 specification to address
this issue:
An application should read all available data from
`environ['wsgi.input']` on POST or PUT requests, even if it does not
process that
At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote:
On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
The Python 3 specific changes are to use:
* ``bytes`` for I/O streams in both directions
* ``str`` for environ keys and values
* ``bytes
Just a reminder: I'm planning to actually update PEP 333 over the
weekend and start working on wsgiref updates, so if you have any
last-minute comments on the proposal, now's the time to post them,
however unpolished they may be!
___
Web-SIG mailing
At 11:11 AM 9/23/2010 -0600, Jeff Hardy wrote:
On Thu, Sep 23, 2010 at 10:06 AM, P.J. Eby p...@telecommunity.com wrote:
So, unless somebody has some additional arguments on this one, I think I'm
going to stick with bytes output.
I don't have a strong opinion on whether it should be bytes
At 02:51 PM 9/23/2010 -0400, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
P.J. Eby wrote:
Just a reminder: I'm planning to actually update PEP 333 over the
weekend and start working on wsgiref updates, so if you have any
last-minute comments on the proposal, now's
At 11:17 AM 9/23/2010 -0500, Ian Bicking wrote:
I don't see any reason why Location shouldn't be ASCII. Any header
could have any character put in it, of course, there's just no valid
case where Location shouldn't be a URL, and URLs are ASCII. Cookie
can contain weirdness, yes. I would
At 03:48 PM 9/23/2010 -0500, Ian Bicking wrote:
It only fixes the one case of non-Latin1 characters, there are still
many other values you can put into a header (a newline or control
character for instance), and innumerable header-specific
issues. It seems to be adding complexity for one of
At 09:52 AM 9/24/2010 -0600, Jeff Hardy wrote:
On Thu, Sep 23, 2010 at 10:32 AM, P.J. Eby p...@telecommunity.com wrote:
Just a reminder: I'm planning to actually update PEP 333 over the weekend
and start working on wsgiref updates, so if you have any last-minute
comments on the proposal
At 01:22 PM 9/24/2010 +0200, René Dudfield wrote:
Hi,
Have all the changes been tested with real world implementations?
mod_wsgi under Python 3 is compliant with the changes, and I believe
it has all the general addenda/clarifications implemented under
Python 2 as well (and for some years
I have only done the Python 3-specific changes at this point; the
diff is here if anybody wants to review, nitpick or otherwise comment:
http://svn.python.org/view/peps/trunk/pep-0333.txt?r1=85014r2=85013pathrev=85014
For that matter, if anybody wants to take a crack at updating Python
3's
At 09:22 PM 9/25/2010 -0400, Jesse Noller wrote:
It seems like it will end up
different enough to be a different specification, closely related to
the original, but different enough to trip up all the people
maintaining current WSGI servers and apps.
The only actual *change* to the spec is
At 02:07 PM 9/25/2010 -0700, Guido van Rossum wrote:
This is a very laudable initiative and I approve of the changes -- but
I really think it ought to be a separate PEP rather than pretending it
is just a set of textual corrections on the existing PEP 333.
With the exception of the bytes
At 07:15 PM 9/25/2010 -0700, Guido van Rossum wrote:
Don't see this as a new spec. See it as a procedural issue.
As a procedural issue, PEP 333 is an Informational PEP, in Draft
status, which I'd like to make Final after these amendments. See
http://www.wsgi.org/wsgi/Amendments_1.0, which
At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw ba...@python.org wrote:
On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote:
At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote:
I'm happy approving Final status for the
*original* PEP 333 and I'm
-- maybe mark up the
differences in PEP so people can easily tell what was added. And
move PEP 333 to Final status.
--Guido
On Sun, Sep 26, 2010 at 1:50 PM, P.J. Eby p...@telecommunity.com wrote:
At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw
At 02:59 PM 9/26/2010 -0400, Terry Reedy wrote:
You could mark added material is a way that does not conflict with
rst or html. Or use .rst to make new text stand out in the .html web
verion (bold, underlined, red, or whatever). People familiar with
333 can focus on the marked sections. New
At 12:04 PM 10/4/2010 -0400, P.J. Eby wrote:
PEP has now been updated with the amendments and clarifications
that I announced two weeks ago; see this link for the (nicely
formatted) differences between PEP 333 and PEP :
http://svn.python.org/view/peps/trunk/pep-.txt?r1=85014r2
A preliminary update of the standalone (Python 3.x) version of
wsgiref is now available using easy_install wsgiref==dev. Relevant
diffs are here:
http://svn.eby-sarna.com/?rev=2689view=rev
This is preliminary work that'll need to be ported to the Python 3
version of wsgiref (note that the
At 01:28 PM 10/6/2010 +0200, And Clover wrote:
On 10/05/2010 04:23 AM, P.J. Eby wrote:
A preliminary update of the standalone (Python 3.x) version of wsgiref
is now available
Is there any interest in putting fixup code into wsgiref's
CGIHandler? I appreciate this is really ugly, but the CGI
At 10:35 AM 10/22/2010 +1100, Graham Dumpleton wrote:
Any one care to comment on my blog post?
http://blog.dscpl.com.au/2010/10/is-pep--final-solution-for-wsgi-on.html
As far as web framework developers commenting, Armin at:
As I've been tidying up wsgiref in the stdlib for PEP , I've been
noticing that there's a bit of an issue with the PEP as far as CGI variables.
Currently, the CGI example is the same as it is in PEP , which
means that it's correct code for Python 2.x, but wrong for 3.x due to
the
At 05:04 PM 1/2/2011 +1100, Graham Dumpleton wrote:
That PEP was rejected in the end and was
replaced with PEP 342 which worked quite differently, yet I cant see
that the WSGI specification was revisited in light of how it ended up
being implemented and the implications of that.
Part of my
At 12:38 PM 1/2/2011 -0800, Alice BevanMcGregor 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
At 02:21 PM 1/2/2011 -0800, Alice BevanMcGregor 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
At 04:43 PM 1/3/2011 -0800, Guido van Rossum wrote:
On Mon, Jan 3, 2011 at 3:13 PM, Jacob Kaplan-Moss ja...@jacobian.org wrote:
On Sun, Jan 2, 2011 at 9:21 AM, Guido van Rossum gu...@python.org wrote:
Although [PEP ] is still marked as draft, I personally think of it
as accepted; [...]
At 08:04 PM 1/3/2011 -0500, Randy Syring wrote:
In the server/gateway example, there is a comment in the code that says:
# TODO: this needs to be binary on Py3
The TODO part confuses me. In other areas of the PEP, there are
comments like:
# call must be byte-safe on Py3
which make sense.
At 06:30 PM 1/3/2011 -0800, Guido van Rossum wrote:
Would
sys.stdout.buffer.write(b'abc')
do?
(If you mix this with writing strings to sys.stdout directly, you may
have to call sys.stdout.flush() first.)
The current code is:
sys.stdout.write(data) # TODO: this needs to be
At 12:43 PM 1/4/2011 +, Antoine Pitrou wrote:
Alice BevanMcGregor al...@... writes: [1]
http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of
the CGI server example in this new SWGI spec? This is 2011, and we
should promote modern idioms, not encourage people to do 1995 Web
At 09:51 PM 1/4/2011 +1100, Graham Dumpleton wrote:
Add another point. FWIW, these are coming up because of questions
being asked on python-dev IRC channel about PEP .
The issue as it came down to was that the PEP may not be clear enough
in explaining that where str() is unicode and as such
At 08:53 PM 1/4/2011 +1100, Graham Dumpleton wrote:
BTW, to what extent are the examples in the PEP meant to be able to
work on both Python 2.X and Python 3.X as is.
Does it need to be clarified where examples will only work on Python
3.X, in particular the CGI gateway.
The intention is that
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
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
At 05:00 PM 1/7/2011 +1100, Graham Dumpleton wrote:
Stupid question first. When running 2to3 on the example CGI code,
Don't do that. It's supposed to already be Python 3 code. ;-)
It did, however, reveal a bug where I have not in fact done the
correct Python 3 thing:
if
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
At 01:17 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome by
incorporatingthe most common (1%) of features most often
relegated to middlewareor functional helpers.
Note that nearly every application
1 - 100 of 116 matches
Mail list logo
