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. car
On Wed, Sep 23, 2009 at 2:38 PM, P.J. Eby wrote:
> 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 Pyt
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
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 script
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
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 somet
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"
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. Giv
At 09:22 PM 9/22/2009 -0500, 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 primarily to "native" strings: str on both Python 2 and 3.
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 prim
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 v
11 matches
Mail list logo
