classification
Title: Unicode email address helper
Type: enhancement Stage: resolved
Components: Library (Lib), Unicode Versions: Python 3.3
process
Status: closed Resolution: remind
Dependencies: Superseder:
Assigned To: r.david.murray Nosy List: eric.araujo, loewis, r.david.murray, zenzen
Priority: normal Keywords: patch

Created on 2004-05-31 23:36 by zenzen, last changed 2011-04-06 14:18 by r.david.murray. This issue is now closed.

Files
File name Uploaded Description Edit
EmailAddress.py zenzen, 2004-09-07 05:34
test_EmailAddress.py zenzen, 2004-09-07 05:38
Messages (6)
msg46105 - (view) Author: Stuart Bishop (zenzen) Date: 2004-05-31 23:36
Converting email addresses between Unicode and ASCII is non 
trivial, as three different encodings are used (RFC2047, IDNA and 
ASCII). Here is an EmailAddress I use and a test suite, which I feel 
should be integrated into the email package. I'm quite happy to 
implement a different interface if the 'unicode subclass' design is 
unsuitable, although I got no feedback from the Email-SIG so they 
are either happy with it or asleep ;)

msg46106 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-08-25 13:18
Logged In: YES 
user_id=21627

I think it is inappropriate to create new API for this.
Instead, one of the many functions that already deal with
address parsing need to be enhanced. For example,
email.Util.formataddr should learn to format unicode
strings, too. Likewise, parseaddr could grow a parameter
do_unicode, or a second function parseaddr_unicode could be
added. There is IMO no need for a new class.

In addition, this patch lacks documentation and test cases.
msg46107 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-08-25 13:19
Logged In: YES 
user_id=21627

Oops, test cases are there - only documentation is lacking.
msg46108 - (view) Author: Stuart Bishop (zenzen) Date: 2004-09-07 05:30
Logged In: YES 
user_id=46639

I think that adding options to the existing APIs simply makes the Unicode 
support feel tacked on (as it would be). It is also error prone, where if 
you are following best practice and using Unicode everywhere, you have 
to remember to explicitly pass the 'do_unicode=True' parameter to this 
one particular function.

I think the alternative approach would be to use a codec, similar to how 
Unicode DNS domains are handled 
('foo@example.com'.decode('emailaddress')).

I still prefer the OO approach though, as it allows the programmer to 
treat email addresses as a standard Unicode string with a few extra 
features, such as the __cmp__ method I've since added to 
EmailAddress.py and the test suite:

>>> e = EmailAddress(u'renee@ol\u00e9.de', u'Rene\u00e9 Acut\u00e9')
>>> e == str(e)
True
>>> e == unicode(e)
True
>>> e == str(EmailAddress(e.upper()))
True
>>> e == unicode(EmailAddress(e.upper()))
True
msg110565 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-07-17 15:10
I'm assigning this to myself so I don't lose it.  I'll need to incorporate the intent of the tests and logic into email6.  And yes I set 3.3 on purpose...email6 won't be in 3.2 and I don't want to spend the cycles figuring out whether this would work in email5 (the 3.2 version of email).
msg133134 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-04-06 14:18
Issue 1690608 addresses part of this issue, and issue 11783 will address the IDNA part.

From my point of view those two issues solve this problem from the perspective the email package infrastructure and *current* API.  In the email6 API I do plan to have an address helper class that will make managing addresses more conveniently OO, but that is part of the whole email6 process and I don't feel a need any longer to keep this issue open.  There's no good value for 'resolution' to express the resolution here (I've accepted the idea but not the code), so I used 'remind', since I will be coming back to the idea in a little while.
History
Date User Action Args
2011-04-06 14:18:22r.david.murraysetstatus: open -> closed
resolution: remind
messages: + msg133134

stage: patch review -> resolved
2010-12-27 17:04:58r.david.murrayunlinkissue1685453 dependencies
2010-07-17 15:10:08r.david.murraysetassignee: r.david.murray
messages: + msg110565
versions: + Python 3.3, - Python 2.7
2010-07-17 09:53:04eric.araujosetnosy: + eric.araujo, r.david.murray
2009-03-30 22:56:23ajaksu2linkissue1685453 dependencies
2009-02-14 13:56:03ajaksu2setstage: patch review
type: enhancement
components: + Unicode
versions: + Python 2.7, - Python 2.4
2004-05-31 23:36:08zenzencreate