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 r.david.murray
Recipients barry, mitya57, r.david.murray
Date 2012-03-21.15:47:29
SpamBayes Score 7.86434e-10
Marked as misclassified No
Message-id <1332344850.97.0.945705606079.issue14360@psf.upfronthosting.co.za>
In-reply-to
Content
Well, a patch won't get committed if it lacks tests, so commit would have to wait until I have time to write some, then.

The encode_ methods (from email.encoders) take *message* objects as their arguments.  MIMEText internally converts a byte string into the appropriate CTE *if* you give it a charset (if you don't it later produces an error, but that's a different bug).  So if you pass bytes you don't need to call an encode_ method separately.

In fact, there's really no reason to call an encode_ method at all, since if you pass a string to MIMEText when giving it a non-ascii unicode string, it will default to utf-8 and do the appropriate CTE encoding.

But given that they exist in the documented API and exist in Python2, they need to be fixed to work in an equivalent fashion in Python3.  I think the only case where they would do anything useful is if you don't like Python's default for the CTE encoding and want to change it.  (Note that you can accomplish that globally by updating the charset alias in the charset module.)

What is your use case, by the way?
History
Date User Action Args
2012-03-21 15:47:31r.david.murraysetrecipients: + r.david.murray, barry, mitya57
2012-03-21 15:47:30r.david.murraysetmessageid: <1332344850.97.0.945705606079.issue14360@psf.upfronthosting.co.za>
2012-03-21 15:47:30r.david.murraylinkissue14360 messages
2012-03-21 15:47:29r.david.murraycreate