[issue2645] httplib throws ValueError

[Georg Brandl]

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]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1738] filecmp.dircmp does exact match only

[Michael Amrhein]

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 isn't. 
I can't imagine a good reason for this and would like to change it by
also applying os.name.normcase to each name in ignore and hide.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2658] decode_header() fails on multiline headers

[Christoph Schneeberger]

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 regex part, that renders such headers invalid and they
won't be parsed as expected.
Given the following header line (doesn't matter if its parsed from a
mail or read from a string) which represents IMHO a valid RFC2047 header
line:

from email.Header import decode_header
decode_header('=?windows-1252?Q?=22M=FCller_T=22?=\r\n <[EMAIL PROTECTED]>')

this will result in:
header.py (54371):
[('=?windows-1252?Q?=22M=FCller_T=22?=\r\n <[EMAIL PROTECTED]>', None)]

resp. with header.py (54370):
[('"M\xfcller T"', 'windows-1252'), (' <[EMAIL PROTECTED]>', None)]

Actually both seem parsed wrong, but with 54370 the result looks more
sane (the space should be IMO removed). 
Once the CRLF sequence is removed from the header it works fine and all
looks as expected:
>>> decode_header('=?windows-1252?Q?=22M=FCller_T=22?= <[EMAIL PROTECTED]>')
[('"M\xfcller T"', 'windows-1252'), ('<[EMAIL PROTECTED]>', None)]

This problem might or might not be related to 
- issue 1372770 
- issue 1467619

(1) http://svn.python.org/view?rev=54371&view=rev

--
components: Library (Lib)
messages: 65630
nosy: cschnee
severity: normal
status: open
title: decode_header() fails on multiline headers
type: behavior
versions: Python 2.4, Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2658] decode_header() fails on multiline headers

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
assignee:  -> barry
nosy: +barry

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2639] shutil.copyfile() documentation is vague

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Fixed in r62389.

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Fixed in r62390.

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Fixed in r62391.

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2631] IMPORT_NAME Documentation is incomplete

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Fixed in r62392.

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2659] textwrap handling of hyphenation

[Sylvain Fourmanoit]

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 guide.

Initial discussion started here:
http://mail.python.org/pipermail/stdlib-sig/2008-April/000265.html

--
components: Library (Lib)
files: textwrap_hyphens_doc.patch
keywords: patch
messages: 65635
nosy: fourmanoit
severity: normal
status: open
title: textwrap handling of hyphenation
versions: Python 2.6
Added file: http://bugs.python.org/file10061/textwrap_hyphens_doc.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2659] textwrap handling of hyphenation

[Sylvain Fourmanoit]

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://bugs.python.org/file10062/textwrap_break_on_hyphens.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2659] textwrap handling of hyphenation

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
assignee:  -> georg.brandl
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Brandon Ehle]

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 prepended on the front.

RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File "/usr/local/bin/2to3", line 5, in 
sys.exit(refactor.main())
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 81, in main
rt.refactor_args(args)
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 188, in
refactor_args
self.refactor_file(arg)
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 217, in
refactor_file
input = f.read() + "\n" # Silence certain parse errors
  File "/usr/local/lib/python3.0/io.py", line 1611, in read
decoder.decode(self.buffer.read(), final=True))
  File "/usr/local/lib/python3.0/io.py", line 1199, in decode
output = self.decoder.decode(input, final=final)
  File "/usr/local/lib/python3.0/codecs.py", line 300, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 59-60:
invalid data

--
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3bug.py
messages: 65637
nosy: azverkan, collinwinter
severity: normal
status: open
title: 2to3 throws a utf8 decode error on a iso-8859-1 string
versions: Python 3.0
Added file: http://bugs.python.org/file10063/2to3bug.py

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Collin Winter]

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/collinwinter/Desktop/2to3bug.py 
  File "/home/collinwinter/Desktop/2to3bug.py", line 3
[EMAIL PROTECTED]:~/src/python/py3k

This suggests this problem isn't 2to3-specific. Refiling this issue
against py3k's Unicode support.

--
assignee: collinwinter -> 
components: +Unicode -2to3 (2.x to 3.0 conversion tool)
priority:  -> high

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2661] Mapping tests cannot be passed by user implementations

[David Anderson]

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 repr() is applied. It is unclear why this is
required of conforming mapping protocol implementations.
 - TestMappingProtocol.test_fromkeys() cannot pass for any
implementation that uses its constructor in fromkeys(), because baddict1
defines a constructor accepting no arguments. It should accept *args,
**kwargs to be sane for user implementations that handle passing data
sources to the constructor.
 - TestHashMappingProtocol.test_mutatingiteration(), for some faulty
implementations, makes the iteration degrade into an infinite loop.
Making the test more strict (eg. keeping an explicit iteration count and
failing if it goes >1) would be more helpful to buggy implementations.

These all seem like trivial issues. If it is agreed that the repr_test
should be removed from the ABC tests, I can provide a patch implementing
these three corrections.

--
components: Library (Lib)
messages: 65639
nosy: danderson
severity: normal
status: open
title: Mapping tests cannot be passed by user implementations
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Collin Winter]

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]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2645] httplib throws ValueError

[Gregory P. Smith]

Gregory P. Smith <[EMAIL PROTECTED]> added the comment:

could you backport that to release25-maint if it isn't there already?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Brandon Ehle]

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 fails under 2.5 and 2.6 instead.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Brandon Ehle]

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]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com