This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yves@zioup.com
Recipients barry, r.david.murray, vunruh, yves@zioup.com
Date 2011-02-13.18:36:13
SpamBayes Score 6.386893e-08
Marked as misclassified No
Message-id <1297622174.75.0.9939864207.issue9298@psf.upfronthosting.co.za>
In-reply-to
Content
encoders.py:
Fixes the issue of base64'ed being > 76 chars


test_email.py:

-test that base64'ed binary is split into 76 chars lines

-WARRNING: Changes the test for MIMEApplication.test_body:
    -it changes the name of the variable 'bytes' to 'bytesdata'
    -it strip()s the base64ed payload before it compares it to the expected payload. With the change above (using encodebytes instead of b64encode in encoders.py), this test, as is, fails, because there is an extra newline at the end. Extra newlines are part of base64 and should not be an issue, as a matter of fact, you obtain the original bytes when you decode, regardless of having extra newlines. It would be good to know the intent of the original author of this test. Was the intent to ensure there were no newline? If so, why? Or was the intent to simply confirm the base64 encoding conform to the standard? If the latter, my change should not be an issue.

All test ("make test") passed with this patch.
History
Date User Action Args
2011-02-13 18:36:14yves@zioup.comsetrecipients: + yves@zioup.com, barry, r.david.murray, vunruh
2011-02-13 18:36:14yves@zioup.comsetmessageid: <1297622174.75.0.9939864207.issue9298@psf.upfronthosting.co.za>
2011-02-13 18:36:13yves@zioup.comlinkissue9298 messages
2011-02-13 18:36:13yves@zioup.comcreate