Unfortunately we don't have enough history information to determine who wrote the original _bencode function, although very likely it was Barry.  As for the test, that seems to have been written during the python3 translation to make sure that the behavior implemented by _bencode was preserved.  Python2 has no such test: if you remove the newline check from _bencode, the test suite passes.

Checking with RFC 2045, we find this:

   The encoded output stream must be represented in lines of no more
   than 76 characters each.  All line breaks or other characters not
   found in Table 1 must be ignored by decoding software.  In base64
   data, characters other than those in Table 1, line breaks, and other
   white space probably indicate a transmission error, about which a
   warning message or even a message rejection might be appropriate
   under some circumstances.

"All line breaks..." seems pretty unambiguous: an extra trailing newline should be ignored by any compliant email agent.  That does not eliminate the possibility that a non-compliant email agent would tack on an extra newline if there is one after the base64 encoded text, but it seems very very unlikely.  I am therefore inclined to fix the test, as you suggest.

I hope that Barry can remember why _bencode was introduced in the first place, since clearly there was *some* reason.