R. David Murray added the comment: There is no problem with supporting both 2.7 and python3 with the same email API as long as your input strings are ASCII only, which is what is required by the email RFCs (as I said, they do not support unicode...even the new one only supports utf8 (a unicode encoding) not unicode itself). So if your input is RFC compliant (using content transfer encoding to encode non-ASCII characters), things will work fine. Just think of unicode as a 7-bit transmission channel (which is what it is from email's perspective). Otherwise the bytes/string issues are no different than they are for any other shared-code-base application.
I have an extensive doc rewrite in process, but I'm not sure when it will land. I thought I had already added the note about ASCII-only to the parser docs, but I see that I did not. I'll reopen this issue to remind myself to do that, since the doc rewrite will only apply to 3.6 (when the new API will no longer be provisional). ---------- resolution: not a bug -> stage: resolved -> needs patch status: closed -> open title: email.message.get_payload returns wrong encoding -> email parsing docs need to be clear that only ASCII strings are supported versions: +Python 3.4, Python 3.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25545> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
