[issue2645] httplib throws ValueError

Georg Brandl <[EMAIL PROTECTED]> added the comment: The trunk version does already handle this: it closes the connection and raises IncompleteRead. -- resolution: -> out of date status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1738] filecmp.dircmp does exact match only

Michael Amrhein <[EMAIL PROTECTED]> added the comment: There is one small issue I would like to discuss: While the comparison of directory and file names in phase1 is case-insensitive on case-insensitive systems (os.path.normcase applied to each name), the filtering of ignore and hide in phase0 i

[issue2658] decode_header() fails on multiline headers

New submission from Christoph Schneeberger <[EMAIL PROTECTED]>: email.Header.decode_header() does not correctly deal with multiline Headerlines. header.py in revision 54371 (1) changes the behaviour, whereas previously multiline headers where parsed correctly, header.py 54371 introduced a new reg

[issue2658] decode_header() fails on multiline headers

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- assignee: -> barry nosy: +barry __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mai

[issue2639] shutil.copyfile() documentation is vague

Georg Brandl <[EMAIL PROTECTED]> added the comment: Fixed in r62389. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue2634] os.execvpe() docs need to be more specific

Georg Brandl <[EMAIL PROTECTED]> added the comment: Fixed in r62390. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue2633] Improve subprocess.Popen() documentation ("env" parameter)

Georg Brandl <[EMAIL PROTECTED]> added the comment: Fixed in r62391. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue2631] IMPORT_NAME Documentation is incomplete

Georg Brandl <[EMAIL PROTECTED]> added the comment: Fixed in r62392. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue2659] textwrap handling of hyphenation

New submission from Sylvain Fourmanoit <[EMAIL PROTECTED]>: The textwrap module in standard library breaks hyphenated words given the opportunity; I don't think that's absolutely obvious from the current doc, and it's something worth mentioning. Here is a short addition to the library reference

[issue2659] textwrap handling of hyphenation

Sylvain Fourmanoit <[EMAIL PROTECTED]> added the comment: I also think it would be nice if a public interface to completely avoid breaking hyphenated words would be included; patch included: it's pretty light, and should have no impact on any code currently using textwrap. Added file: http://bug

[issue2659] textwrap handling of hyphenation

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- assignee: -> georg.brandl nosy: +georg.brandl __ Tracker <[EMAIL PROTECTED]> __ ___ Python

[issue2660] 2to3 throws a utf8 decode error on a iso-8859-1 string

New submission from Brandon Ehle <[EMAIL PROTECTED]>: While running the 2to3 script on the scons codebase, I ran into an UnicodeDecodeError. Attached is just the portion of the script that causes the error. 2to3 throws an error on the string regardless of whether the unicode string literal is p

[issue2660] 2to3 throws a utf8 decode error on a iso-8859-1 string

Collin Winter <[EMAIL PROTECTED]> added the comment: 2to3 running under Python 2.5.1 handles this file just fine. 2to3 running under 3.0a4+ (r62404) fails as detailed below. However, that file doesn't run correctly under Python itself: [EMAIL PROTECTED]:~/src/python/py3k$ ./python /home/collinwi

[issue2661] Mapping tests cannot be passed by user implementations

New submission from David Anderson <[EMAIL PROTECTED]>: Some test cases in Lib/test/mapping_tests.py are problematic for users wishing to test their own implementations of the mapping protocol: - TestHashMappingProtocol.test_repr() requires the user implementations to look like a dict when rep

[issue2660] Py3k fails to parse a file with an iso-8859-1 string

Changes by Collin Winter <[EMAIL PROTECTED]>: -- title: 2to3 throws a utf8 decode error on a iso-8859-1 string -> Py3k fails to parse a file with an iso-8859-1 string __ Tracker <[EMAIL PROTECTED]> _

[issue2645] httplib throws ValueError

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: could you backport that to release25-maint if it isn't there already? __ Tracker <[EMAIL PROTECTED]> __ _

[issue2660] Py3k fails to parse a file with an iso-8859-1 string

Brandon Ehle <[EMAIL PROTECTED]> added the comment: Someone on the #python IRC channel suggested that the default for python 3.0 for unicode string literals is reversed from python 2.5. If you remove the unicode string literal (u'') from the front of the string, it runs fine under python 3.0 and

[issue2660] Py3k fails to parse a file with an iso-8859-1 string

Brandon Ehle <[EMAIL PROTECTED]> added the comment: Also, I can confirm that running 2to3 with Python 2.6 correctly converts the script but running 2to3 with Python 3.0 results in a UnicodeDecodeError exception. __ Tracker <[EMAIL PROTECTED]>