[issue4718] wsgiref package totally broken

Benjamin Peterson added the comment: I assume the buildbots were placated? -- nosy: +benjamin.peterson resolution: accepted -> fixed status: pending -> closed ___ Python tracker

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: Nice catch! I've committed the two patches and we'll see whether it makes the buildbots feel better. -- resolution: -> accepted stage: patch review -> committed/rejected status: open -> pending ___ Python tracker <

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Attached patch for test_urllib, possible source of the "NO_PROXY" problem. Added file: http://bugs.python.org/file12577/no_proxy.patch ___ Python tracker _

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Antoine Pitrou wrote: >> Strange error and it seems there is only part of the traceback. I've >> already seen such "partially displayed" Python 3 traceback and error >> actually can be in very different place. > > If you can reproduce such a problem, please op

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: > Strange error and it seems there is only part of the traceback. I've > already seen such "partially displayed" Python 3 traceback and error > actually can be in very different place. If you can reproduce such a problem, please open a bug. ___

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > There's another problem in that buildbot failure with the environment > variable "NO_PROXY". We'll see if it's still there after the patch. Strange error and it seems there is only part of the traceback. I've already seen such "partiall

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: Le samedi 03 janvier 2009 à 20:24 +, Dmitry Vasiliev a écrit : > Dmitry Vasiliev added the comment: > > Antoine Pitrou wrote: > > People, does this patch look ok to you? > > Oh, didn't know about -bb. Well, it's meant to catch potential bugs. str and byt

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > People, does this patch look ok to you? Oh, didn't know about -bb. The patch looks OK for me. ___ Python tracker ___ __

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: People, does this patch look ok to you? Added file: http://bugs.python.org/file12573/wsgiref-bb.patch ___ Python tracker ___ ___

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: Reopening, the patch actually produces failures when run with "python -bb", that is there are comparisons between str and bytes. See the errors at the end of http://www.python.org/dev/buildbot/3.x.stable/ppc%20Debian%20unstable%203.0/builds/26/step-test/0

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: It is committed now in py3k and the 3.0 maintenance branch. Thanks all for your participation! -- resolution: -> fixed status: open -> closed ___ Python tracker __

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Graham Dumpleton wrote: > Thus have odd situation where with Python 3.0, one could technically return > str as iterable, with rule that would apply would be that each str returned > would then be converted to bytes by way of latin-1 conversion, but for > byt

[issue4718] wsgiref package totally broken

Graham Dumpleton added the comment: One interesting thing of note that has occurred to me looking at the patch is that although with Python <3.0 you technically could return a str as iterable from application, ie., because iteration over str returns str for each character, the same doesn't re

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: Philip, Graham, do you have any objections to the current patch? Otherwise I think I'm gonna commit it soon. ___ Python tracker ___ _

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: Ok, sorry for the misunderstanding. ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > Why do you say they were removed? I see code like "assert > isinstance(value, bytes)". Support and tests for mutable "bytearray" and "memoryview" was removed. All subclasses of "bytes" must be immutable so isinstance() should be OK here

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: Why do you say they were removed? I see code like "assert isinstance(value, bytes)". ___ Python tracker ___ _

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Antoine Pitrou wrote: >> Hmm, it's strange because such tests was removed two versions ago (per >> discussion with Phillip). But at the time they really was needed. > > Not a big deal anyway, let's keep them and we'll see. I'm afraid I've lost your point here

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: > Hmm, it's strange because such tests was removed two versions ago (per > discussion with Phillip). But at the time they really was needed. Not a big deal anyway, let's keep them and we'll see. ___ Python tracker

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > The patch looks ok to me, although the tests against mutable byte-like > types are probably useless. Hmm, it's strange because such tests was removed two versions ago (per discussion with Phillip). But at the time they really was needed

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: Hi, The patch looks ok to me, although the tests against mutable byte-like types are probably useless. ___ Python tracker ___ __

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Added check for wsgi.input.read() argument. Added file: http://bugs.python.org/file12454/wsgiref2.patch ___ Python tracker ___

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Graham Dumpleton wrote: > the check for number of arguments supplied to wsgi.input.read() is wrong as > it allows for an optional argument, > when argument is supposed to mandatory. I think it's a good idea. I'll update the patch soon. _

[issue4718] wsgiref package totally broken

Graham Dumpleton added the comment: If making changes in wsgireg.validate, may be worthwhile also fixing up one area where it isn't strictly correct according to WSGI PEP. As per discussion: http://groups.google.com/group/python-web-sig/browse_frm/thread/b14b862ec4c620c0 the check for numbe

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Attached updated version of the patch. Added file: http://bugs.python.org/file12447/wsgiref.patch ___ Python tracker ___ __

[issue4718] wsgiref package totally broken

Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12439/wsgiref.patch ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Phillip J. Eby wrote: > Graham: thanks for pointing that out; I completely forgot we already > *had* the migration discussion on the Web-SIG! It just slipped my > mind because I didn't have any 3.0 work on the horizon. Good to see we came to conclusion. Act

[issue4718] wsgiref package totally broken

Phillip J. Eby added the comment: Graham: thanks for pointing that out; I completely forgot we already *had* the migration discussion on the Web-SIG! It just slipped my mind because I didn't have any 3.0 work on the horizon. Dmitry: A question about the new patch. Are bytearray and memoryvi

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Attached new WSGI 1.0+ version of the patch. Added file: http://bugs.python.org/file12439/wsgiref.patch ___ Python tracker ___

[issue4718] wsgiref package totally broken

Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12431/wsgiref_pep333.patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue4718] wsgiref package totally broken

Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12429/wsgiref2.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue4718] wsgiref package totally broken

Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12423/wsgiref.patch ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue4718] wsgiref package totally broken

Graham Dumpleton added the comment: Note that the page: http://www.wsgi.org/wsgi/Amendments_1.0 contains clarifications for WSGI PEP in respect of Python 3.0. This list was previously come up with on WEB-SIG list. As another reference implementation for Python 3.0, you might look at mod_wsg

[issue4718] wsgiref package totally broken

Phillip J. Eby added the comment: Antoine, you have three choices here: 1. Follow the PEP, 2. Take it to the Web-SIG and get the appropriate discussion, consensus, and PEP revision, or 3. Drop wsgiref from the current release of Py3K until #2 can be done. Which would you prefer? Please note

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: > No, just as PEP said str used as a container for binary data. This is clearly the wrong thing to do. The only (immutable) string-like object adequate for binary data in py3k is bytes, not str. I understand the desire to stick to the PEP, but the PEP was devi

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > Le mardi 23 décembre 2008 à 11:15 +, Dmitry Vasiliev a écrit : >> OK, I've attached PEP-333 compatible fixes for wsgiref. > > I may be mistaken, but it seems that your patch forces iso-8859-1 > encoding of http bodies. No, just as

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: Le mardi 23 décembre 2008 à 11:15 +, Dmitry Vasiliev a écrit : > Dmitry Vasiliev added the comment: > > OK, I've attached PEP-333 compatible fixes for wsgiref. I may be mistaken, but it seems that your patch forces iso-8859-1 encoding of http bodies. ___

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: > Please read the two paragraphs *after* the one you quoted. I don't see anything forbidding bytes objects in those two paragraphs. ___ Python tracker _

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: OK, I've attached PEP-333 compatible fixes for wsgiref. I think there is only one problem remains: - wsgiref expects io.BytesIO as input and output streams because of http.server module. I didn't find any restrictions on data returned by read() method of the "

[issue4718] wsgiref package totally broken

Phillip J. Eby added the comment: To be quite clear: this change requires discussion on the Web-SIG and an appropriate revision of the PEP. Ideally, the patch should include the necessary PEP revision. The Web-SIG discussion regarding a switch to bytes should also take into consideration the e

[issue4718] wsgiref package totally broken

Phillip J. Eby added the comment: At 03:37 PM 12/22/2008 +, Antoine Pitrou wrote: >So, not accepting bytes in py3k is clearly a violation of the PEP! On the contrary. Please read the two paragraphs *after* the one you quoted. ___ Python tracker

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: New version of the patch: - Now only Unicode strings are allowed as status and headers because allowing bytes leads to big changes in wsgiref.validate and wsgiref.handlers; -- versions: -Python 3.1 Added file: http://bugs.python.org/file12429/wsgiref

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Antoine Pitrou wrote: >> If you want to change to using bytes, you're going to have to take it >> to the Web-SIG and hash out a revision to PEP 333, which at the moment >> requires the use of strings, period. > > What was called str in 2.x has become the bytes

[issue4718] wsgiref package totally broken

Changes by Antoine Pitrou : -- priority: critical -> release blocker stage: -> patch review versions: +Python 3.1 ___ Python tracker ___ _

[issue4718] wsgiref package totally broken

Dmitry Vasiliev added the comment: Antoine Pitrou wrote: > FYI, instead of trying to do exhaustive type checking in _check_type(), > you can just rely on duck typing and catch the TypeError: Good point! I'll update the patch soon. ___ Python tracker

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: > If you want to change to using bytes, you're going to have to take it > to the Web-SIG and hash out a revision to PEP 333, which at the moment > requires the use of strings, period. What was called str in 2.x has become the bytes object in py3k. What was call

[issue4718] wsgiref package totally broken

Phillip J. Eby added the comment: If you want to change to using bytes, you're going to have to take it to the Web-SIG and hash out a revision to PEP 333, which at the moment requires the use of strings, period. This has nothing to do with the desirability of bytes vs. strings; I am sure that i

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: FYI, instead of trying to do exhaustive type checking in _check_type(), you can just rely on duck typing and catch the TypeError: >>> str(b"a", "utf-8") 'a' >>> str(bytearray(b"a"), "utf-8") 'a' >>> str(memoryview(b"a"), "utf-8") 'a' >>> str(1, "utf-8") Traceba

[issue4718] wsgiref package totally broken

Antoine Pitrou added the comment: Phillip, do you have time to take a look at it? We really *must* fix wsgiref in py3k... -- nosy: +pitrou, pje priority: -> critical ___ Python tracker

[issue4718] wsgiref package totally broken

New submission from Dmitry Vasiliev : It seems the wsgiref package was copied from Python 2.* without any modifications. There are already 3 issues about that but they only describe a part of the problem so I decided to start a new one. The issues was: http://bugs.python.org/issue3348 http://bug