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
23 matches
Mail list logo
