-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
P.J. Eby wrote:
So you better believe that everybody else is going to copy the worst
available examples of other people's WSGI code and ignore any
documentation associated with it... and then they will expect it to
work on your server. ;-)
On Sep 22, 2009, at 8:28 PM, P.J. Eby wrote:
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
OK, that's quite exhaustive.
For the benefit of those of us jumping in, could you summarise your
proposal in something like the following manner:
1. How the request method is made available to WSGI applications
2. How the request-uri is made available to WSGI applications -- in
particular,
2009/9/22 P.J. Eby p...@telecommunity.com:
I'm tending to flip-flop a bit myself
For the record, I am doing that as well.
Graham
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
2009/9/22 Mark Nottingham m...@mnot.net:
OK, that's quite exhaustive.
For the benefit of those of us jumping in, could you summarise your proposal
in something like the following manner:
1. How the request method is made available to WSGI applications
2. How the request-uri is made
So, what advice do you propose about decoding bytes into strings for
the request-URI / method / request headers, and vice versa for
response headers and status code/phrase? Do you assume ASCII, Latin-1,
or UTF-8? How are errors handled?
Are bodies still treated as binary byte sequences, as
2009/9/22 Mark Nottingham m...@mnot.net:
So, what advice do you propose about decoding bytes into strings for the
request-URI / method / request headers, and vice versa for response headers
and status code/phrase? Do you assume ASCII, Latin-1, or UTF-8? How are
errors handled?
Are bodies
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? Requiring all comers to read such a
voluminous entry is a considerable (and somewhat arbitrary) bar
It's not a specific proposal, but here's my opinions on what a proposal
should be:
On Tue, Sep 22, 2009 at 1:06 AM, Mark Nottingham m...@mnot.net wrote:
OK, that's quite exhaustive.
For the benefit of those of us jumping in, could you summarise your
proposal in something like the following
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? Requiring all comers to read such a voluminous
entry is a
You're twisting my words; nowhere did I say i wasn't willing to read
the PEP. What I did say was that a proposal can and should be made in
less than eleven pages; I'd like to give my feedback, both because I
use Python and because I have some interest in HTTP. However, my time
is limited,
[Ian]
OK, another proposal entirely: we kill SCRIPT_NAME and PATH_INFO
introduce two equivalent variables that hold the NOT url-decoded values.
[Graham]
That may be fine for pure Python web servers where you control the
split of REQUEST_URI into SCRIPT_NAME and PATH_INFO in the first place
[Ian]
When things get messed up I recommend people use a middleware
(paste.deploy.config.PrefixMiddleware, though I don't really care what they
use) to fix up the request to be correct. Pulling it from REQUEST_URI would
be fine.
That would be unworkable under java servlet containers, since
2009/9/22 Mark Nottingham m...@mnot.net:
You're twisting my words; nowhere did I say i wasn't willing to read the
PEP. What I did say was that a proposal can and should be made in less than
eleven pages; I'd like to give my feedback, both because I use Python and
because I have some interest
Hi,
P.J. Eby schrieb:
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, so the code is already written.
On 22/09/2009, at 6:11 PM, Armin Ronacher wrote:
Hi,
Mark Nottingham schrieb:
HTTP headers *are* ASCII; RFC2616 defined them to be ISO-8859-1, but
HTTPbis currently takes the stance that they're ASCII, as in practice
Latin-1 isn't used and may introduce interop problems.
In practise
Hi,
Ian Bicking schrieb:
Request headers, which you didn't split out... those I'm not sure. I'd
*like* them to be native. But damn, I'm just not sure quite how.
surrogateescape? Latin1? Latin1 as a kind of poor man's surrogateescape
isn't so bad. And the headers *should* be ASCII for
[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, so the code is already written.
[Armin]
Except
On Tue, Sep 22, 2009 at 3:16 AM, Armin Ronacher armin.ronac...@active-4.com
wrote:
Hi,
Ian Bicking schrieb:
Request headers, which you didn't split out... those I'm not sure. I'd
*like* them to be native. But damn, I'm just not sure quite how.
surrogateescape? Latin1? Latin1 as a
Hi,
Alan Kennedy schrieb:
So, if nobody implements that, then why are we trying to standardise it?
I think that was just one of the ideas that were discussed.
Just to sum it up a bit where we already went:
- my initial plan was going bytes everywhere. Turns out, on Python 3
this is nearly
[Alan]
Is there a real need out there?
[Armin]
In python 3, yes. Because the stdlib no longer works with bytes and the
bytes object has few string semantics left.
Why can't we just do the same as the java servlet spec? I.E.
1. Ignore the encoding issues being discussed
2. Give the
[Armin]
Because that problem was solved a long ago in applications themselves.
Webob, Werkzeug, Paste, Pylons, Django, you name it, all are operating
on unicode. And the way they do that is straightforward.
So what are we all discussing?
Those frameworks obviously have solved all of the
[Armin]
No, they know the character sets.
Hmmm, define know ;-)
[Armin]
You tell them what character set you
want to use. For example you can specify utf-8, and they will
decode/encode from/to utf-8. But there is no way for the application to
send information to the server before they are
On Tue, Sep 22, 2009 at 10:06 AM, Alan Kennedy a...@xhaus.com wrote:
[Alan]
Is there a real need out there?
[Armin]
In python 3, yes. Because the stdlib no longer works with bytes and the
bytes object has few string semantics left.
Why can't we just do the same as the java servlet spec?
Hi,
Alan Kennedy schrieb:
Hmmm, define know ;-)
The charset of incoming data, the charset of URLs, the charset of
outgoing data, the charset of whatever the application uses, is what the
application decides it to be. Most new applications go with utf-8 for
everything these days.
I see this as
[Armin]
Of course a server configuration variable would be a solution for many
of these problems, but I don't like the idea of changing application
behavior based on server configuration.
So you don't like the way that Django, Werkzeug, WebOb, etc, do it
now, even though they appear to be
On Tue, Sep 22, 2009 at 12:12 PM, Armin Ronacher
armin.ronac...@active-4.com wrote:
Hi,
Alan Kennedy schrieb:
So you don't like the way that Django, Werkzeug, WebOb, etc, do it
now, even though they appear to be mostly successful, and you're happy
to cite them as such?
Server !=
Thank you Armin this makes things clear to me ( a newbie hre).
On Sep 22, 2009, at 3:29 AM, Armin Ronacher wrote:
- my initial plan was going bytes everywhere. Turns out, on Python 3
this is nearly impossible to do because the majority of the standard
library went an unicode path, even where
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 in
P.J. Eby [mailto:p...@telecommunity.com]
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
Alan Kennedy wrote:
Why can't we just do the same as the java servlet spec?
Because Servlet is a walking, stinking demonstration of how *not* to
handle encodings.
Every servlet container has its own different method of selecting input
character sets, and the default encoding is almost
Hi,
And Clover schrieb:
This is absolutely the opposite of what I want as an application author.
I want to hand out my WSGI application that uses UTF-8 and know that
wherever it is deployed the non-ASCII characters will go through without
getting mangled.
I could not agree more.
Probably
+1
On Sep 22, 2009, at 10:45 AM, Armin Ronacher wrote:
Hi,
And Clover schrieb:
This is absolutely the opposite of what I want as an application
author.
I want to hand out my WSGI application that uses UTF-8 and know that
wherever it is deployed the non-ASCII characters will go through
Graham wrote:
Armin has fast asleep now, so my shift.
Heh. It's a multiple-man job keeping up with this monster thread!
The URLs don't break.
Not in themselves. Just the language of the PEP implies that to fix them
up would contravene the spec:
The application MUST use [the encoding
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 in the WSGI
dictionary, so that applications that
On Sep 22, 2009, at 2:28 AM, 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 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
Hi,
Robert Brewer schrieb:
urllib.unquote, for one. We had to make a version which accepts bytes
(and outputs bytes). But it's only 8 lines of code.
Here a patch for urllib.parse that restores Python 2.x behavior.
Because it also changes behavior for Python 3.x I have not yet submitted
it for
On Sun, Sep 20, 2009 at 11:25 PM, Chris McDonough chr...@plope.com wrote:
WSGI is a fairly low-level protocol aimed at folks who need to interface a
server to the outside world. The outside world (by its nature) talks bytes.
I fear that any implied conversion of environment values and
Hi,
James Bennett schrieb:
Well, ordinarily I'd be inclined to agree: HTTP deals in bytes, so an
interface to HTTP should deal in bytes as well.
If it was just that I would be happy to stay with bytes. But unless the
standard library changes in the way it works on Python 3 there is not
much
On Mon, Sep 21, 2009 at 1:28 AM, Armin Ronacher
armin.ronac...@active-4.com wrote:
If it was just that I would be happy to stay with bytes. But unless the
standard library changes in the way it works on Python 3 there is not
much but unicode we can use. bytes no longer behave like strings,
OK, after some consideration, I think I'm sold.
Answering my own original question about why unicode seems to make sense as
values in the WSGI environment even without consideration for Python 3
compatibility: *something* needs to do this translation. Currently I
personally rely on WebOb to
On Mon, Sep 21, 2009 at 7:28 AM, Armin Ronacher
armin.ronac...@active-4.com wrote:
Hi,
James Bennett schrieb:
Well, ordinarily I'd be inclined to agree: HTTP deals in bytes, so an
interface to HTTP should deal in bytes as well.
If it was just that I would be happy to stay with bytes. But
On Mon, Sep 21, 2009 at 8:10 AM, Chris McDonough chr...@plope.com wrote:
OTOH, I suspect the Python 3 stdlib is still broken if it requires native
strings in various places (and prohibits the use of bytes).
yes, python3 stdlib should support 'str'(the old unicode), 'buffer'
and 'bytes' for web
René Dudfield schrieb:
On Mon, Sep 21, 2009 at 8:10 AM, Chris McDonough
chrism-ccarnewbnkgavxtiumw...@public.gmane.org wrote:
OTOH, I suspect the Python 3 stdlib is still broken if it requires native
strings in various places (and prohibits the use of bytes).
yes, python3 stdlib should
On Mon, Sep 21, 2009 at 9:46 AM, Georg Brandl g.bra...@gmx.net wrote:
René Dudfield schrieb:
On Mon, Sep 21, 2009 at 8:10 AM, Chris McDonough
chrism-ccarnewbnkgavxtiumw...@public.gmane.org wrote:
OTOH, I suspect the Python 3 stdlib is still broken if it requires native
strings in various
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 specification that requires Unicode.
Bonus points for an
On Mon, Sep 21, 2009 at 4:27 PM, James Bennett ubernost...@gmail.com wrote:
On Mon, Sep 21, 2009 at 10:19 AM, P.J. Eby p...@telecommunity.com wrote:
+1. I'd really rather not have the spec dictated by the need to work around
problems in the stdlib or language definition. Better to fix them
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
On Mon, Sep 21, 2009 at 4:42 PM, P.J. Eby p...@telecommunity.com wrote:
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
On Sun, Sep 20, 2009 at 8:06 AM, Armin Ronacher
armin.ronac...@active-4.com wrote:
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
P.J. Eby wrote:
At 07:57 AM 9/21/2009 +0200, Armin Ronacher wrote:
Chris McDonough schrieb:
Personally, I find it a bit hard to get excited about Python 3 as
a
web application deployment platform.
Everybody feels that way currently. But if we don't fix WSGI that
will never change.
On Mon, Sep 21, 2009 at 11:09:24AM -0500, Ian Bicking wrote:
I think surrogateescape can resolve the small handful of problems.
+1
surrogateescape would be a great alternative to the try utf-8 then
latin-1 approach. It would simplify the gateway and the application. No
need to check some
Armin Ronacher wrote:
The middleware can never know.
It's much more likely than to know than the server though!
WSGI will demand UTF-8 URLs and only
provide iso-XXX support for backwards compatibility.
It doesn't sound much like backwards compatibility to me if non-UTF-8
URLs break as
René Dudfield wrote:
On Mon, Sep 21, 2009 at 6:05 PM, Robert Brewer fuman...@aminus.org
wrote:
Armin Ronacher wrote:
WSGI will demand UTF-8 URLs and only
provide iso-XXX support for backwards compatibility.
WSGI cannot demand that; a recommendation for utf-8 in a few draft
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
On Mon, Sep 21, 2009 at 8:31 PM, P.J. Eby p...@telecommunity.com wrote:
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
P.J. Eby wrote:
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
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
On Mon, Sep 21, 2009 at 09:14:13PM +0200, Armin Ronacher wrote:
So the same standard should have different behavior on different Python
versions? That would make framework code a lot more complicated.
I don't understand why it would be 'a lot more' complicated.
(The following code snippets is
Henry Precheur wrote:
On Mon, Sep 21, 2009 at 09:14:13PM +0200, Armin Ronacher wrote:
So the same standard should have different behavior on different
Python versions? That would make framework code a lot more
complicated.
I don't understand why it would be 'a lot more' complicated.
On Mon, Sep 21, 2009 at 03:26:35PM -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
2009/9/22 Henry Precheur he...@precheur.org:
On Mon, Sep 21, 2009 at 03:26:35PM -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
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
HTTP headers *are* ASCII; RFC2616 defined them to be ISO-8859-1, but
HTTPbis currently takes the stance that they're ASCII, as in practice
Latin-1 isn't used and may introduce interop problems.
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-07#section-4.2
Historically,
+1. There is no one answer for these issues (e.g., URI-IRI conversion
can lose information), so low-level infrastructure like WSGI shouldn't
be making choices for people.
On 22/09/2009, at 5:31 AM, P.J. Eby wrote:
At 11:23 AM 9/21/2009 -0700, Robert Brewer wrote:
I still don't see why the
Most things is not the Web. How will you handle serving images through
WSGI? Compressed content? PDFs?
On 22/09/2009, at 1:30 AM, René Dudfield wrote:
here is a summary:
Apart from python3 compatibility(which should be good enough
reason), utf-8 is what's used in http a lot these days.
+1
On Sep 21, 2009, at 8:28 PM, Mark Nottingham wrote:
+1. There is no one answer for these issues (e.g., URI-IRI conversion
can lose information), so low-level infrastructure like WSGI shouldn't
be making choices for people.
On 22/09/2009, at 5:31 AM, P.J. Eby wrote:
At 11:23 AM 9/21/2009
2009/9/22 Mark Nottingham m...@mnot.net:
Most things is not the Web. How will you handle serving images through WSGI?
Compressed content? PDFs?
You are perhaps misunderstanding something. A WSGI application still
should return bytes.
The whole concept of any sort of fallback to allow unicode
Reference?
On 22/09/2009, at 12:07 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham m...@mnot.net:
Most things is not the Web. How will you handle serving images
through WSGI?
Compressed content? PDFs?
You are perhaps misunderstanding something. A WSGI application still
should
2009/9/22 Mark Nottingham m...@mnot.net:
Reference?
See:
http://blog.dscpl.com.au/2009/09/roadmap-for-python-wsgi-specification.html
Anyone else jumping in on this conversation with their own opinions
and who has not read it, should perhaps at least read that. Also read
some of the earlier
Armin has fast asleep now, so my shift. :-)
He did point me to this specific email for closer attention,
indicating issues with QUERY_STRING and wsgi.uri_encoding due to
something mentioned here. I didn't quite get what he was talking
about, but then I believe he has some wrong statements in his
Henry Precheur wrote:
On Mon, Sep 21, 2009 at 03:26:35PM -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
On Mon, Sep 21, 2009 at 07:40:54PM -0700, Robert Brewer wrote:
The decoding doesn't change spontaneously.
You either get the correct one or you get an incorrect one. If it's
incorrect, you fix it, one time, via a WSGI component which you've
configured to determine the correct decoding. Then
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*
On Mon, Sep 21, 2009 at 6:16 PM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
Of course you can directly use `environ['some_key']` if you know you'll
get the 'right' encoding all the time. But when the encoding changes,
you'll have to fix all your middlewares.
I am missing
2009/9/22 Ian Bicking i...@colorstudy.com:
On Mon, Sep 21, 2009 at 6:16 PM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
Of course you can directly use `environ['some_key']` if you know you'll
get the 'right' encoding all the time. But when the encoding changes,
you'll have to fix
On Tue, Sep 22, 2009 at 12:21 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
That may be fine for pure Python web servers where you control the
split of REQUEST_URI into SCRIPT_NAME and PATH_INFO in the first place
but don't have that luxury in Apache or via FASTCGI/SCGI/CGI etc as
2009/9/22 Ian Bicking i...@colorstudy.com:
On Tue, Sep 22, 2009 at 12:21 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
That may be fine for pure Python web servers where you control the
split of REQUEST_URI into SCRIPT_NAME and PATH_INFO in the first place
but don't have that luxury
On Tue, Sep 22, 2009 at 12:38 AM, Graham Dumpleton
graham.dumple...@gmail.com wrote:
If doing something like you suggest, would prefer them as 'wsgi.'
prefixed variables and not put in all upper case namespace to be
confused with CGI variables etc.
I just had to make up a name, but I agree
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 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
Hi,
P.J. Eby schrieb:
This discussion has been going on for so long that I've already
forgotten what the problem was with just using the original 1.0 spec
for 3.X, i.e., using native strings for everything, using latin-1
encoding. The only things I can recall off the top of my head are
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
P.J. Eby schrieb:
- Python 3 no longer implicitly converts between unicode and byte
strings. This covers comparisons, the regular expression engine,
all string functions and many modules in the stdlib.
- The Python 3 stdlib radically moved to unicode for non unicode things
as well
2009/9/21 Armin Ronacher armin.ronac...@active-4.com:
IMO, this strongly suggests that it's the stdlib or Python 3 that's
broken here. How much of the stdlib are we talking about needing to
reimplement, aside from cgi.FieldStorage?
I'm already creating a patch for urllib which currently
Armin Ronacher wrote:
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 currently is
WSGI 1.1 becomes what Ian
P.J. Eby wrote:
At 03:06 PM 9/20/2009 +0200, Armin Ronacher wrote:
The following things became pretty clear when playing around with
various specifications on Python 3:
- Python 3 no longer implicitly converts between unicode and byte
strings. This covers comparisons, the regular
I'll try to digest some of this, currently I'm pretty clueless.
Personally, I find it a bit hard to get excited about Python 3 as a web
application deployment platform. This is of course a personal judgment (I
don't mean to slight Python 3) but at this point, I'll think I'll probably be
+1
On Sep 20, 2009, at 11:25 PM, Chris McDonough wrote:
I'll try to digest some of this, currently I'm pretty clueless.
Personally, I find it a bit hard to get excited about Python 3 as a
web
application deployment platform. This is of course a personal
judgment (I
don't mean to slight
Hi,
Chris McDonough schrieb:
Personally, I find it a bit hard to get excited about Python 3 as a web
application deployment platform.
Everybody feels that way currently. But if we don't fix WSGI that will
never change.
Given this point of view, it would be extremely helpful if someone could
96 matches
Mail list logo
