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.

Title: email.utils.formataddr encodes incorrectly
Type: behavior Stage:
Components: email, Library (Lib) Versions: Python 2.7
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: Michael.JasonSmith, barry, r.david.murray
Priority: normal Keywords:

Created on 2014-03-03 18:14 by Michael.JasonSmith, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg212648 - (view) Author: Michael JasonSmith (Michael.JasonSmith) Date: 2014-03-03 18:14
The email.utils.formataddr function is used to encode a name-address 2-tuple for use as an email message. If the name contains a non-ASCII character it needs to be encoded. This happens correctly in Python 3.3.2, but incorrectly in Python 2.7.5. Ideally Python 2 would acquire the Python 3 behaviour, as this should make porting easier.

In the following Python 3.3.2 example the name is encoded because of the non-ASCII ☢ character:
>>> import email.utils
>>> name = 'Me ☢'
>>> addr = ''
>>> email.utils.formataddr((name, addr))
'=?utf-8?b?TWUg4pii?= <>'

In Python 2.7.5 the same name is incorrectly left unaltered:
>>> import email.utils
>>> name = u'Me ☢'
>>> addr = ''
>>> email.utils.formataddr((name, addr))
u'Me \u2622 <>'

However, calling the email.header.Header.encode method works around this issue in Python 2:
>>> import email.utils
>>> import email.header
>>> name = u'Me ☢'
>>> addr = ''
>>> h = email.header.Header(name)
>>> email.utils.formataddr((h.encode(), addr))
'=?utf-8?b?TWUg4pii?= <>'

The example code immediately above also works in Python 3; it is the current work-around in GroupServer. However, ideally instances of Unicode objects passed to email.utils.formataddr will work the same in both Python 2 and Python 3.
msg212650 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-03 18:22
At the time we introduced this behavior in python3, it was considered an enhancement and thus not suitable for backporting.  So you'd have to advocate for backporting it on python-dev.  My guess is it won't be approved, especially since there are significant other differences in the python2 vs python3 email packages (eg: BytesParser/BytesGenerator).
msg212651 - (view) Author: Michael JasonSmith (Michael.JasonSmith) Date: 2014-03-03 18:37
I care enough to lodge an issue, but I lack the conviction in order to belabour the point in python-dev! I'll mark this issue as closed.

Hopefully the work-around in my original post will help others :)
msg212654 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-03 19:07
Well, the "work around" was how you always had to do it in python2.  So this is just a bit you can't port to the easier Python3 interface until you can drop python2 support.
Date User Action Args
2022-04-11 14:57:59adminsetgithub: 65044
2014-03-03 19:07:45r.david.murraysetmessages: + msg212654
2014-03-03 18:37:16Michael.JasonSmithsetstatus: open -> closed
resolution: wont fix
messages: + msg212651
2014-03-03 18:23:16r.david.murraysetnosy: + barry

components: + email
versions: - Python 3.2
2014-03-03 18:22:20r.david.murraysetnosy: + r.david.murray
messages: + msg212650
2014-03-03 18:14:53Michael.JasonSmithcreate