Michael Henry pyt...@drmikehenry.com added the comment:
David,
Your patch looks fine to me. I like putting the logic is a
separate class as you've done. I looked in itertools for
something to perform the job of the each_last() generator I'd
had in my patch, but I didn't see anything. I like
R. David Murray rdmur...@bitdance.com added the comment:
I turns out that issue 5803 has a patch that also fixes this bug, and the
algorithm used there is even more efficient than the one you've developed here.
However, it is also not compatible with the email5 version of quoprimime. It
Roundup Robot devnull@devnull added the comment:
New changeset 37ba11d806c5 by R David Murray in branch '3.1':
#11606: improved body_encode algorithm, no longer produces overlong lines
http://hg.python.org/cpython/rev/37ba11d806c5
New changeset b801d55a9979 by R David Murray in branch '3.2':
Changes by R. David Murray rdmur...@bitdance.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11606
R. David Murray rdmur...@bitdance.com added the comment:
Michael, in general your approach looks sound and is much easier to read and
comprehend than the original code (which, as the comments say, was never
refined from the original quick and dirty hack). However, rather than
dynamically
New submission from Michael Henry pyt...@drmikehenry.com:
The email module's body_encode() function (found in
quoprimime.py) can generate oversized encoded lines that exceed
the maximum line length specified by the maxlinelen parameter.
The attached test case
Changes by R. David Murray rdmur...@bitdance.com:
--
assignee: - r.david.murray
stage: - patch review
type: - behavior
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
