[issue3714] nntplib module broken by str to unicode conversion
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>:
The following commands fail badly:
>>> from nntplib import NNTP
>>> s = NNTP("free-text.usenetserver.com")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/nntplib.py", line 116, in __init__
self.welcome = self.getresp()
File "/py3k/Lib/nntplib.py", line 215, in getresp
resp = self.getline()
File "/py3k/Lib/nntplib.py", line 209, in getline
elif line[-1:] in CRLF: line = line[:-1]
TypeError: 'in ' requires string as left operand, not bytes
Actually there are many places in nntplib module which need to be
converted to bytes, or socket input/output values need to be converted
from/to str. I think API need to be updated to pass user defined
encoding at some stages. I can make a patch later if needed.
--
components: Library (Lib)
messages: 72090
nosy: hdima
severity: normal
status: open
title: nntplib module broken by str to unicode conversion
type: crash
versions: Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3714>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3714] nntplib module broken by str to unicode conversion
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: I've attached the patch which adds encoding parameter to the NNTP class. -- keywords: +patch Added file: http://bugs.python.org/file11292/nntplib.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3714> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3725] telnetlib module broken by str to unicode conversion
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>:
Simple example:
>>> from telnetlib import Telnet
>>> t = Telnet("google.com", 80)
>>> t.write("GET / HTTP/1.1\r\n")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/telnetlib.py", line 280, in write
self.sock.sendall(buffer)
TypeError: sendall() argument 1 must be string or buffer, not str
>>> t.write(b"GET / HTTP/1.1\r\n")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/telnetlib.py", line 277, in write
if IAC in buffer:
TypeError: Type str doesn't support the buffer API
--
components: Library (Lib)
messages: 72131
nosy: hdima
severity: normal
status: open
title: telnetlib module broken by str to unicode conversion
type: crash
versions: Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3725>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3725] telnetlib module broken by str to unicode conversion
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: I think only bytes need to be allowed for write() and read*() because of low-level nature of Telnet. I can create a patch later. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3725> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3727] poplib module broken by str to unicode conversion
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>:
Example:
>>> from poplib import POP3
>>> p = POP3("localhost")
>>> p.user("user")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/poplib.py", line 179, in user
return self._shortcmd('USER %s' % user)
File "/py3k/Lib/poplib.py", line 151, in _shortcmd
self._putcmd(line)
File "/py3k/Lib/poplib.py", line 98, in _putcmd
self._putline(line)
File "/py3k/Lib/poplib.py", line 91, in _putline
self.sock.sendall('%s%s' % (line, CRLF))
TypeError: sendall() argument 1 must be string or buffer, not str
>>> p.user(b"user")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/poplib.py", line 179, in user
return self._shortcmd('USER %s' % user)
File "/py3k/Lib/poplib.py", line 151, in _shortcmd
self._putcmd(line)
File "/py3k/Lib/poplib.py", line 98, in _putcmd
self._putline(line)
File "/py3k/Lib/poplib.py", line 91, in _putline
self.sock.sendall('%s%s' % (line, CRLF))
TypeError: sendall() argument 1 must be string or buffer, not str
--
components: Library (Lib)
messages: 72136
nosy: hdima
severity: normal
status: open
title: poplib module broken by str to unicode conversion
type: crash
versions: Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3727>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3728] imaplib module broken by str to unicode conversion
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>:
Example:
>>> from imaplib import IMAP4
>>> m = IMAP4("localhost")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/imaplib.py", line 185, in __init__
self.welcome = self._get_response()
File "/py3k/Lib/imaplib.py", line 912, in _get_response
if self._match(self.tagre, resp):
File "/py3k/Lib/imaplib.py", line 1021, in _match
self.mo = cre.match(s)
TypeError: can't use a string pattern on a bytes-like object
>>> m = IMAP4(b"localhost")
Traceback (most recent call last):
File "", line 1, in
File "/py3k/Lib/imaplib.py", line 185, in __init__
self.welcome = self._get_response()
File "/py3k/Lib/imaplib.py", line 912, in _get_response
if self._match(self.tagre, resp):
File "/py3k/Lib/imaplib.py", line 1021, in _match
self.mo = cre.match(s)
TypeError: can't use a string pattern on a bytes-like object
--
components: Library (Lib)
messages: 72137
nosy: hdima
severity: normal
status: open
title: imaplib module broken by str to unicode conversion
type: crash
versions: Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3728>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3728] imaplib module broken by str to unicode conversion
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: Ah, yes. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3728> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3714] nntplib module broken by str to unicode conversion
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment:
Actually RFC-977 said all characters must be in ASCII, but RFC-3977
changed default character set to UTF-8. So I think UTF-8 must be default
encoding, not Latin-1. Moreover Latin-1 can silently hide a real
encoding, for example:
>>> u'\u0422\u0435\u0441\u0442'.encode("koi8-r").decode("latin1")
u'\xf4\xc5\xd3\xd4'
Additionally in the future it would be a good idea to look in the
article headers for article body encoding.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3714>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3714] nntplib module broken by str to unicode conversion
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: If I understand it correctly there is no "character set used by server" because every article can be in different encoding. RFC-3977 say: """ The character set of article bodies SHOULD be indicated in the article headers, and this SHOULD be done in accordance with MIME. """ But it's not always true, for example fido7.* groups known to use "KOI-8R" encoding but I didn't find any relevant headers. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3714> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3714] nntplib module broken by str to unicode conversion
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: RFC-3977 say the following about headers: - The names of headers (e.g., "From" or "Subject") MUST be in US-ASCII. - Header values SHOULD use US-ASCII or an encoding based on it, such as RFC 2047 [RFC2047], until such time as another approach has been standardised. At present, 8-bit encodings (including UTF-8) SHOULD NOT be used because they are likely to cause interoperability problems. But in practice for now there is no way to reliable find a header's encoding. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3714> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3935] bisect insort C implementation ignores methods on list subclasses
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: Actually it was an optimization. PyList_Insert() was used for list and list-derived objects. I've attached the patch which fix the issue and for me the new code looks even cleaner than the original code. -- keywords: +patch nosy: +hdima Added file: http://bugs.python.org/file11614/bisect.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3935> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3935] bisect insort C implementation ignores methods on list subclasses
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: Good idea! Don't know why I didn't use it in the very first version. :-) New patch attached. Added file: http://bugs.python.org/file11623/bisect2.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3935> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3714] nntplib module broken by str to unicode conversion
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: Oh, you need to read the comments first: - Use of ISO-8859-1 it's a bad idea here. See msg72776 for details. Moreover RFC-3977 explicitly say about UTF-8, so I think we need to use UTF-8. - Maybe set_encoding() isn't needed but you need to have a possibility to change encoding after object creation. Because different groups can use different encodings. But with makefile() addition you just remove this possibility. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3714> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3725] telnetlib module broken by str to unicode conversion
Dmitry Vasiliev <[EMAIL PROTECTED]> added the comment: The patch is good. It's exactly what I told about in msg72132. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3725> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4363] Make uuid module functions usable without ctypes
New submission from Dmitry Vasiliev <[EMAIL PROTECTED]>: The attached patch removes dependency on ctypes from uuid.uuid1() and uuid.uuid4() functions. -- components: Library (Lib) files: uuid.patch keywords: patch messages: 76107 nosy: hdima severity: normal status: open title: Make uuid module functions usable without ctypes type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12071/uuid.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4363> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue3795 http://bugs.python.org/issue4522 The attached patch fix the problem with the following changes: - Fixed headers handling in wsgiref/simple_server.py; - Fixed encoding problems. Now WSGI applications must return iterable with bytes but start_response() allow status and headers as bytes and as strings. "wsgi.input" file-like now use BytesIO instead of StringIO; - Fixed tests; - Updated documentation examples; -- components: Library (Lib) files: wsgiref.patch keywords: patch messages: 78171 nosy: hdima severity: normal status: open title: wsgiref package totally broken type: crash versions: Python 3.0 Added file: http://bugs.python.org/file12423/wsgiref.patch ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 object in py3k. > What was called unicode in 2.x has become str in py3k. > (roughly) Agreed, moreover it's time for Python 3.0.1 and we need to decide - apply a patch or just remove wsgiref completely for now. Keep wsgiref just as nonworking piece of code is the worse solution which can made questionable all WSGI effort. Given that old str has been replaced by bytes in Python 3 I think the patch is a correct implementation of the PEP from the Python 3's point of view. To avoid confusion note about the meaning of the term *string* can be added to the PEP later. ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/wsgiref2.patch ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 "wsgi.input" stream in the PEP. Maybe I've missed some details? Added file: http://bugs.python.org/file12431/wsgiref_pep333.patch ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Dmitry Vasiliev added the comment:
Antoine Pitrou wrote:
> Le mardi 23 décembre 2008 à 11:15 +0000, 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 PEP said str used as a container for binary data. For
example to return UTF-8 encoded data you can use the following code:
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
didn't notice this sections before):
"""
On Python platforms where the str or StringType type is in fact
Unicode-based (e.g. Jython, IronPython, Python 3000, etc.), all
"strings" referred to in this specification must contain only code
points representable in ISO-8859-1 encoding (\u through \u00FF,
inclusive). It is a fatal error for an application to supply strings
containing any other Unicode character or code point. Similarly, servers
and gateways must not supply strings to an application containing any
other Unicode characters.
Again, all strings referred to in this specification must be of type str
or StringType, and must not be of type unicode or UnicodeType. And, even
if a given platform allows for more than 8 bits per character in
str/StringType objects, only the lower 8 bits may be used, for any value
referred to in this specification as a "string".
"""
We definitely need to use bytes in the future but it requires PEP update
and some migration guide.
___
Python tracker
<http://bugs.python.org/issue4718>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12423/wsgiref.patch ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12429/wsgiref2.patch ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12431/wsgiref_pep333.patch ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. Actually my first patch went in the right direction. :-) > Dmitry: A question about the new patch. Are bytearray and memoryview > objects in 3.0 really the same as bytestrings? It seems to me that > allowing mutable bytes objects is a mistake from a bug-finding > standpoint, even if it could be a win from a performance > standpoint. I think it might be better to be more restrictive to > start out, and then let people lobby for supporting other types, > rather than the other way around, where we'll never get to narrow the > list. Apart from that, the patch looks pretty good. Thank you! Actually I thought about functionality, not performance but I think you're right and mutable bytes objects also can open doors for unexpected side effects. I'll update the patch today. ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Changes by Dmitry Vasiliev : Removed file: http://bugs.python.org/file12439/wsgiref.patch ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4604] close() seems to have limited effect
Dmitry Vasiliev added the comment: Attached more generic version of the patch. -- nosy: +hdima Added file: http://bugs.python.org/file12450/io_fixes.patch ___ Python tracker <http://bugs.python.org/issue4604> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. Are you proposing to add back tests for mutable bytes-like objects? ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4778] Small typo in multiprocessing documentation
New submission from Dmitry Vasiliev : Small typo about "call" Process.daemon flag. The patch attached. -- assignee: georg.brandl components: Documentation files: multiprocessing.patch keywords: patch messages: 78516 nosy: georg.brandl, hdima severity: normal status: open title: Small typo in multiprocessing documentation versions: Python 3.0 Added file: http://bugs.python.org/file12491/multiprocessing.patch ___ Python tracker <http://bugs.python.org/issue4778> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 > bytes returned as iterable, should fail. > > Not sure how this plays out in wsgiref server yet as haven't looked. If application return bytes instead of an iterable AssertionError will be raised in handlers.BaseHandler.write(). ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 "partially displayed" Python 3 traceback and error actually can be in very different place. ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 open a bug. OK, I'll try to reproduce. ___ Python tracker <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue4718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5742] inspect.findsource() should look only for sources
New submission from Dmitry Vasiliev : Currently help(zlib) gives the following traceback: Python 3.1a2+ (py3k:71538M, Apr 12 2009, 21:54:44) >>> import zlib >>> help(zlib) Traceback (most recent call last): File "", line 1, in File "Lib/site.py", line 429, in __call__ return pydoc.help(*args, **kwds) File "Lib/pydoc.py", line 1709, in __call__ self.help(request) File "Lib/pydoc.py", line 1755, in help else: doc(request, 'Help on %s:') File "Lib/pydoc.py", line 1505, in doc pager(render_doc(thing, title, forceload)) File "Lib/pydoc.py", line 1500, in render_doc return title % desc + '\n\n' + text.document(object, name) File "Lib/pydoc.py", line 320, in document if inspect.ismodule(object): return self.docmodule(*args) File "Lib/pydoc.py", line 1086, in docmodule contents.append(self.document(value, key, name)) File "Lib/pydoc.py", line 321, in document if inspect.isclass(object): return self.docclass(*args) File "Lib/pydoc.py", line 1131, in docclass doc = getdoc(object) File "Lib/pydoc.py", line 81, in getdoc result = inspect.getdoc(object) or inspect.getcomments(object) File "Lib/inspect.py", line 581, in getcomments lines, lnum = findsource(object) File "Lib/inspect.py", line 524, in findsource lines = linecache.getlines(file, module.__dict__) File "Lib/linecache.py", line 41, in getlines return updatecache(filename, module_globals) File "Lib/linecache.py", line 127, in updatecache lines = fp.readlines() File "Lib/codecs.py", line 300, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 41-42: invalid data After some investigation I've found that inspect.findsource() try to use getfile() if getsourcefile() fail to find the source file. I don't see why findsource() should return lines from a compiled file so I think it's a bug. The same bug also exists in Python 2.7 although it's not so critical. I've attached the patch which fixes the problem. -- components: Library (Lib) files: inspect.patch keywords: patch messages: 85916 nosy: hdima severity: normal status: open title: inspect.findsource() should look only for sources type: crash versions: Python 3.1 Added file: http://bugs.python.org/file13678/inspect.patch ___ Python tracker <http://bugs.python.org/issue5742> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
