Ian wrote:
some environments provide only the unquoted path. I think it's not
terribly horrible if they fake it by re-quoting the path.
If they are faking it, there should IMO be a way to flag that it's
faked. Then an application that uses IRIs may choose to
a. generate an error, or
b.
Hi,
Ian Bicking schrieb:
I propose we switch primarily to native strings: str on both Python 2 and
3.
I'm starting to think that this is the best idea.
I then propose that we eliminate SCRIPT_NAME and PATH_INFO. Instead we
have:
IMO they should stick around for compatibility with older
Ian Bicking wrote:
I propose we switch primarily to native strings: str on both Python 2 and
3.
Fine.
wsgi.input remains byte-oriented, as does the response app_iter.
Good.
These both form the original path. It is not URL decoded, so it should be
ASCII.
Great! BUT.
Undecoded
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
OK, I mentioned this in the last thread, but... I can't keep up with all
this discussion, and I bet you can't either.
So, here's a rough proposal for WSGI and unicode:
I propose we switch primarily to native strings: str on both Python 2 and
3.
Specifically:
environ keys: native
environ CGI
Hello Ian,
I really like your proposal.
Massimo
On Sep 22, 2009, at 9:22 PM, Ian Bicking wrote:
OK, I mentioned this in the last thread, but... I can't keep up with
all this discussion, and I bet you can't either.
So, here's a rough proposal for WSGI and unicode:
I propose we switch
On Sep 22, 2009, at 10:22 PM, Ian Bicking wrote:
I propose we switch primarily to native strings: str on both
Python 2 and 3.
[...]
All [...] headers will be treated as Latin1.
I like this. I think it would be cleaner to use bytes for all these
things, but it's not really important. Given
On Tue, Sep 22, 2009 at 11:26:15PM -0400, P.J. Eby wrote:
+1, if you mean the strings have the same content,
character-for-character on Python 2.3. That is, a \x80 byte in a
Python 2 'str' is matched by an \x80 character in the Python 3
'str'. (I presume that's what we mean by native, but
On Tue, Sep 22, 2009 at 09:22:48PM -0500, Ian Bicking wrote:
Well, the biggie: is it right to use native strings for the environ values,
and response status/headers? Specifically, tricks like the latin1
transcoding won't work in Python 2, but will in Python 3. Is this weird?
Or just
