On Dec 9, 2007 7:56 PM, Graham Dumpleton [EMAIL PROTECTED] wrote:
On 09/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote:
On Dec 8, 2007 12:37 AM, Graham Dumpleton [EMAIL PROTECTED] wrote:
On 08/12/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
* When running under Python 3, servers MUST
On 08/12/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
* When running under Python 3, servers MUST provide a text stream for
wsgi.errors
In Python 3, what happens if user code attempts to output to a text
stream a byte string? Ie., what would be displayed?
Also, if wsgi.errors is a text
On Dec 8, 2007 12:37 AM, Graham Dumpleton [EMAIL PROTECTED] wrote:
On 08/12/2007, Phillip J. Eby [EMAIL PROTECTED] wrote:
* When running under Python 3, servers MUST provide a text stream for
wsgi.errors
In Python 3, what happens if user code attempts to output to a text
stream a byte
[Alan]
The restriction to iso-8859-1 is really a distraction; iso-8859-1 is
used simply as an identity encoding that also enforces that all
bytes in the string have a value from 0x00 to 0xff, so that they are
suitable for byte-oriented IO. So, in output terms at least, WSGI *is*
a
[Phillip]
WSGI already copes, actually. Note that Jython and IronPython have
this issue today, and see:
http://www.python.org/dev/peps/pep-0333/#unicode-issues
[James]
It would seem very odd, however, for WSGI/python3 to use strings-
restricted-to-0xFF for network I/O while everywhere else
Phillip J. Eby wrote:
So here are my recommendations so far for the addendum to WSGI *1.0* for
Python 3.0 (I expect we can be more strict for WSGI 2.0):
* When running under Python 3, applications SHOULD produce bytes output
and headers
* When running under Python 3, servers and
So here are my recommendations so far for the addendum to WSGI *1.0*
for Python 3.0 (I expect we can be more strict for WSGI 2.0):
* When running under Python 3, applications SHOULD produce bytes
output and headers
* When running under Python 3, servers and gateways MUST accept
strings as
On Dec 7, 2007, at 5:46 PM, Andrew Clover wrote:
OTOH making the dictionaries reflect the underlying OS's conception of
environment variables means users of os.environ and WSGI will have
to be
able to cope with both bytes and unicode, which would also be a big
annoyance.
In summary:
James Y Knight wrote:
In addition, I know of nobody who actually implements RFC 2047
decoding of http header values...nothing really uses it. (of
course I don't know of all implementations out there.)
Certainly no browser supports it, which makes the point moot for WSGI.
Most browsers, when
Adam Atlas [EMAIL PROTECTED] wrote:
I'd say it would be best to only accept `bytes` objects
+1. HTTP is inherently byte-based. Any translation between bytes and
unicode characters should be done at a higher level, by whatever web
framework is living above WSGI.
--
And Clover
mailto:[EMAIL
On Dec 7, 2007, at 2:55 PM, Phillip J. Eby wrote:
* When running under Python 3, servers MUST provide CGI HTTP
variables as strings, decoded from the headers using HTTP standard
encodings (i.e. latin-1 + RFC 2047) (Open question: are there any
CGI or WSGI variables that should NOT be
At 10:13 AM 12/7/2007 +1100, Graham Dumpleton wrote:
Has anyone had any thoughts about how WSGI is going to made to work
with Python 3?
From what I understand about changes in Python 3, the main issue seems
to be the removal of string type in its current form.
This is an issue as WSGI
On Dec 6, 2007 4:15 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 10:13 AM 12/7/2007 +1100, Graham Dumpleton wrote:
Has anyone had any thoughts about how WSGI is going to made to work
with Python 3?
From what I understand about changes in Python 3, the main issue seems
to be the removal
On Dec 6, 2007, at 7:15 PM, Phillip J. Eby wrote:
WSGI already copes, actually. Note that Jython and IronPython have
this issue today, and see:
http://www.python.org/dev/peps/pep-0333/#unicode-issues
On Python platforms where the str or StringType type is in fact
Unicode-based (e.g.
At 08:08 PM 12/6/2007 -0500, Adam Atlas wrote:
On 6 Dec 2007, at 18:13, Graham Dumpleton wrote:
In Python 3 the default for string type objects will effectively be
Unicode. Is WSGI going to be made to somehow cope with that, or will
application instead be required to return byte string
On 6 Dec 2007, at 18:13, Graham Dumpleton wrote:
In Python 3 the default for string type objects will effectively be
Unicode. Is WSGI going to be made to somehow cope with that, or will
application instead be required to return byte string objects instead?
I'd say it would be best to only
On Dec 6, 2007 6:15 PM, Phillip J. Eby [EMAIL PROTECTED] wrote:
WSGI already copes, actually. Note that Jython and IronPython have
this issue today, and see:
http://www.python.org/dev/peps/pep-0333/#unicode-issues
I'm glad you brought that up, because it's been bugging me lately.
That
Phillip J. Eby wrote:
At 08:08 PM 12/6/2007 -0500, Adam Atlas wrote:
On 6 Dec 2007, at 18:13, Graham Dumpleton wrote:
In Python 3 the default for string type objects will effectively be
Unicode. Is WSGI going to be made to somehow cope with that, or will
application instead be required to
On Dec 6, 2007 8:00 PM, Ian Bicking [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
At 08:08 PM 12/6/2007 -0500, Adam Atlas wrote:
On 6 Dec 2007, at 18:13, Graham Dumpleton wrote:
In Python 3 the default for string type objects will effectively be
Unicode. Is WSGI going to be made to
19 matches
Mail list logo
