Author r.david.murray
Recipients belopolsky, eric.smith, lavajoe, r.david.murray
Date 2011-01-21.15:17:39
SpamBayes Score 2.16728e-06
Marked as misclassified No
Message-id <1295623061.61.0.941149278437.issue10947@psf.upfronthosting.co.za>
In-reply-to
Content
Well, we recently added support for parsing binary data streams to the email module (or added back, if you are looking at it from a python2 perspective), exactly because "in the wild" headers are not always RFC compliant ASCII, and because bodies often are RFC *compliant* 8bit.  So yes, the appropriate type for imaplib to be returning is bytes, and the application has to figure out how to decode it to string using the information contained internally in the email message.  The email package is the obvious way to do this, and if there are helper routines that an imaplib programmer would want in order to make that job easier, those would be very legitimate feature requests (but most of what one needs should already be there; specifically decode_header and friends, although there's an outstanding feature request for a convenience wrapper around that).
History
Date User Action Args
2011-01-21 15:17:41r.david.murraysetrecipients: + r.david.murray, belopolsky, eric.smith, lavajoe
2011-01-21 15:17:41r.david.murraysetmessageid: <1295623061.61.0.941149278437.issue10947@psf.upfronthosting.co.za>
2011-01-21 15:17:39r.david.murraylinkissue10947 messages
2011-01-21 15:17:39r.david.murraycreate