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 Pytho
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 provide a text stream for
> > > wsgi.errors
> >
> > In Pyt
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
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 str
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, whe
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 str
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 g
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 appl
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
[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
I wasn't there when PEP-333 was written, nor have I any implication in
any Python development, but here are my thoughts:
2007/12/7, Alan Kennedy:
>
> I think it's worth pointing out the reason for the current restriction
> to iso-8859-1 is *because* python did not have a bytes type at the
> time t
[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 everyw
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
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 r
On Dec 6, 2007 5:45 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 04:27 PM 12/6/2007 -0800, Guido van Rossum wrote:
> >You might want to look at how the unittests for wsgiref manage to pass
> >in Py3k though. ;-)
>
> Unless they've been changed, I'd assume it's because they work with
> strings
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
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 strin
At 04:27 PM 12/6/2007 -0800, Guido van Rossum wrote:
>You might want to look at how the unittests for wsgiref manage to pass
>in Py3k though. ;-)
Unless they've been changed, I'd assume it's because they work with
strings exclusively, and never do any encoding or decoding (which is
outside WSGI'
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 a
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
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
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 sp
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 specification currently states that status,
header names/values
24 matches
Mail list logo
