email.utils.formataddr() should be rfc2047 aware

[warsaw]

BPO	1690608
Nosy	@warsaw, @terryjreedy, @bitdancer
Files	issue-1690608.patch: Contains a test and fix for this issue issue-1690608-v2.patch: Switched to email.charset.Charset, added more tests issue-1690608-v3.patch: Optional arg can be str or Charset, trimmed down tests, added docs. issue-1690608-v4.patch: Checking for instance of str instead of Charset, added 2 more tests for that

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/bitdancer'
closed_at = <Date 2011-04-06.14:04:35.924>
created_at = <Date 2007-03-29.13:27:49.000>
labels = ['easy', 'type-feature', 'library']
title = 'email.utils.formataddr() should be rfc2047 aware'
updated_at = <Date 2011-04-07.09:31:56.092>
user = 'https://github.com/warsaw'

bugs.python.org fields:

activity = <Date 2011-04-07.09:31:56.092>
actor = 'torsten.becker'
assignee = 'r.david.murray'
closed = True
closed_date = <Date 2011-04-06.14:04:35.924>
closer = 'r.david.murray'
components = ['Library (Lib)']
creation = <Date 2007-03-29.13:27:49.000>
creator = 'barry'
dependencies = []
files = ['21429', '21431', '21434', '21436']
hgrepos = []
issue_num = 1690608
keywords = ['patch', 'easy']
message_count = 13.0
messages = ['31677', '113048', '132320', '132331', '132351', '132356', '132367', '132381', '132389', '132390', '133129', '133131', '133202']
nosy_count = 5.0
nosy_names = ['barry', 'terry.reedy', 'r.david.murray', 'python-dev', 'torsten.becker']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1690608'
versions = ['Python 3.3']

[warsaw]

formataddr() should rfc2047 encode its name argument if necessary.

[terryjreedy]

I am just responding so this will not show up on the 'unanswered issues' list.

[torstenbecker]

I implemented a basic test for the issue and an attempt for a fix.

I am not entirely sure with my implementation, specifically I would like to get comments concerning the following points:

• Is is OK that formataddr() will now check if address is ascii safe and if not it will raise a UnicodeEncodeError?

• I was not sure on the style how to append new tests to test_email.py, I just put it into the same spot where all the other formataddr() tests where, shall I put it to the end instead?

I am submitting this patch as part of my preparation for the Google Summer of Code to familiarize myself with the contribution process, any feedback on what I should do different is very welcome.

[bitdancer]

The general approach of the patch looks good to me. Since formataddr is designed to be called from user code that is constructing a message, having it raise for non-ascii in the address is probably OK. However, there should be a test for that, and I'm curious to know what happens if you use such an address in an address field in the unmodified email package.

Instead of directly calling bencode, you should use the charset module and its header_encode method. Note that you need to turn the charset into a Charset instance first. The advantage of doing this is that it will choose the "best" encoding to use based on the charset and the contents of the string.

Your choice of location for the new tests is fine; TestMiscelaneous really should be split up a bit, but that will wait until I do a general refactoring of the tests.

Thanks for working on this.

[torstenbecker]

However, there should be a test for that, and I'm curious to know what happens if you use such an address in an address field in the unmodified email package.

I added a test to check if the exceptions get thrown when a address is invalid.

I also added a small test to check how a resulting message should look, it looks good to me but I am not a specialist with email. Do you have any other ideas how to check if it does not have a negative impact to other parts of the module?

Instead of directly calling bencode, you should use the charset module and its header_encode method. Note that you need to turn the charset into a Charset instance first. The advantage of doing this is that it will choose the "best" encoding to use based on the charset and the contents of the string.

The code also uses email.charset.Charset now.

[bitdancer]

You should check if 'charset' is a string, and call Charset on it only if it is (a Charset may be passed directly in other email package interfaces, and so should be supported here as well.

The test doesn't need to cater for the fact that either b or B (or q or Q) are legitimate: we know which one the package is generating, so just test for that.

For the Message['To'], I wasn't clear. What I would like is a test that includes non-ascii characters in the address part, *without* passing it through formataddr, to see what the package currently does with it. This may in fact reveal an additional bug. But, it is really out of scope for this issue, so you can just remove that test (sorry).

There should also be an update to the docs (Doc/library/email.utils.rst) documenting the API change.