New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wsgiref package totally broken #48968
Comments
It seems the wsgiref package was copied from Python 2.* without any http://bugs.python.org/issue3348 The attached patch fix the problem with the following changes:
|
Phillip, do you have time to take a look at it? We really *must* fix |
FYI, instead of trying to do exhaustive type checking in _check_type(), >>> str(b"a", "utf-8")
'a'
>>> str(bytearray(b"a"), "utf-8")
'a'
>>> str(memoryview(b"a"), "utf-8")
'a'
>>> str(1, "utf-8")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: coercing to str: need string or buffer, int found |
If you want to change to using bytes, you're going to have to take it to This has nothing to do with the desirability of bytes vs. strings; I am In the meantime, as far as I'm aware, there are two other patches |
What was called str in 2.x has become the bytes object in py3k. Given the meaning of the term "string" and its possible acceptions have Actually, the PEP says:
So, not accepting bytes in py3k is clearly a violation of the PEP! |
Antoine Pitrou wrote:
Good point! I'll update the patch soon. |
Antoine Pitrou wrote:
Agreed, moreover it's time for Python 3.0.1 and we need to decide - Given that old str has been replaced by bytes in Python 3 I think the |
New version of the patch:
|
At 03:37 PM 12/22/2008 +0000, Antoine Pitrou wrote:
On the contrary. Please read the two paragraphs *after* the one you quoted. |
To be quite clear: this change requires discussion on the Web-SIG and an The Web-SIG discussion regarding a switch to bytes should also take into The previous choice to use Unicode was based on source compatibility |
OK, I've attached PEP-333 compatible fixes for wsgiref. I think there is
|
I don't see anything forbidding bytes objects in those two paragraphs. |
Le mardi 23 décembre 2008 à 11:15 +0000, Dmitry Vasiliev a écrit :
I may be mistaken, but it seems that your patch forces iso-8859-1 |
Antoine Pitrou wrote:
No, just as PEP said str used as a container for binary data. For def app(environ, start_response):
...
return [data.encode("utf-8").decode("iso-8859-1")] I don't like it but I guess it's strictly follow the PEP (actually I """ Again, all strings referred to in this specification must be of type str We definitely need to use bytes in the future but it requires PEP update |
This is clearly the wrong thing to do. The only (immutable) string-like I understand the desire to stick to the PEP, but the PEP was devised
since "str" objects *are* of type UnicodeType in py3k (and the C API is When a legal text becomes nonsensical wrt. reality, one has to adapt his In other words, wsgiref should accept/expose HTTP bodies as bytes, not |
Antoine, you have three choices here:
Which would you prefer? Please note that your arguments regarding what revision should take However, we have to take into consideration how applications will be Making the change to bytes is not something to be undertaken on a And that's why those three choices are the only available options, so |
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 As another reference implementation for Python 3.0, you might look at |
Attached new WSGI 1.0+ version of the patch. |
Graham: thanks for pointing that out; I completely forgot we already Dmitry: A question about the new patch. Are bytearray and memoryview |
Phillip J. Eby wrote:
Good to see we came to conclusion. Actually my first patch went in the
Actually I thought about functionality, not performance but I think |
Attached updated version of the patch. |
If making changes in wsgireg.validate, may be worthwhile also fixing up one area where it isn't strictly correct As per discussion: http://groups.google.com/group/python-web-sig/browse_frm/thread/b14b862ec4c620c0 the check for number of arguments supplied to wsgi.input.read() is wrong as it allows for an optional argument, |
Graham Dumpleton wrote:
I think it's a good idea. I'll update the patch soon. |
Added check for wsgi.input.read() argument. |
Hi, The patch looks ok to me, although the tests against mutable byte-like |
Antoine Pitrou wrote:
Hmm, it's strange because such tests was removed two versions ago (per |
Not a big deal anyway, let's keep them and we'll see. |
Antoine Pitrou wrote:
I'm afraid I've lost your point here. Are you proposing to add back |
Why do you say they were removed? I see code like "assert |
Antoine Pitrou wrote:
Support and tests for mutable "bytearray" and "memoryview" was removed. |
Ok, sorry for the misunderstanding. |
Philip, Graham, do you have any objections to the current patch? |
One interesting thing of note that has occurred to me looking at the patch Thus have odd situation where with Python 3.0, one could technically return Not sure how this plays out in wsgiref server yet as haven't looked. @@ -426,6 +436,6 @@
# Technically a string is legal, which is why it's a really bad
# idea, because it may cause the response to be returned
# character-by-character
- assert_(not isinstance(iterator, str),
+ assert_(not isinstance(iterator, (str, bytes)),
"You should not return a string as your application iterator, "
"instead return a single-item list containing that string.") quite a good thing to have. |
Graham Dumpleton wrote:
If application return bytes instead of an iterable AssertionError will |
It is committed now in py3k and the 3.0 maintenance branch. Thanks all |
Reopening, the patch actually produces failures when run with "python See the errors at the end of |
People, does this patch look ok to you? |
Antoine Pitrou wrote:
Oh, didn't know about -bb. |
Le samedi 03 janvier 2009 à 20:24 +0000, Dmitry Vasiliev a écrit :
Well, it's meant to catch potential bugs. str and bytes always compare There's another problem in that buildbot failure with the environment |
Antoine Pitrou wrote:
Strange error and it seems there is only part of the traceback. I've |
If you can reproduce such a problem, please open a bug. |
Antoine Pitrou wrote:
OK, I'll try to reproduce. |
Attached patch for test_urllib, possible source of the "NO_PROXY" problem. |
Nice catch! I've committed the two patches and we'll see whether it |
I assume the buildbots were placated? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: