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
'test_encode_trailing_space_at_maxlinelen' demonstrates the
problem.  When encoding the body 'abcd \n1234' with
maxlinelen=5, the erroneous output is 'abcd =\n\n1234', with 6
characters in the first output line.

The attached patch provides unit tests and a fix for
body_encode().  

Note: This patch depends on application of the patch in Issue
#11590.

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 defining sub-functions each time body_encode is called, I've moved the body-construction logic almost completely out of body_encode into a helper object.  I think this further clarifies the algorithm.  I also used a simpler approach to end-of-list detection (enumerate).  That change is more a matter of taste, but does have the advantage of taking fewer lines of code.

If you have time to review this and double check my changes (the tests pass, at least), that would be great.  Otherwise I'll just go ahead and apply it.

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 the idea of
encapsulating the test logic of (index + 1 == len(sequence)) in
some way, as each_last() does, rather than having the caller
calculate it.  If that capability exists somewhere in the Python
standard library, it would be my choice to use that.  If it has
to be built just for this test, though, perhaps it's not worth
the extra lines of code to define each_last().

Michael Henry

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 could be adapted, but I think I'm going to put off considering that until I can take a deeper look at why encode_body takes string as its input.  So I'm going to apply this patch in the meantime.

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':
Merge #11606: improved body_encode algorithm, no longer produces overlong lines
http://hg.python.org/cpython/rev/b801d55a9979

New changeset 0c40f4939174 by R David Murray in branch 'default':
Merge #11606: improved body_encode algorithm, no longer produces overlong lines
http://hg.python.org/cpython/rev/0c40f4939174