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.

classification
Title: headerregistry.Address introduces extra quotes without addr_spec parameter
Type: behavior Stage:
Components: email Versions: Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: barry, krother, r.david.murray
Priority: normal Keywords:

Created on 2014-10-01 21:25 by krother, last changed 2022-04-11 14:58 by admin.

Files
File name Uploaded Description Edit
test_email_address_with_quotes.py krother, 2014-10-01 21:25 unit tests reproducing the problem
Messages (2)
msg228128 - (view) Author: Kristian Rother (krother) Date: 2014-10-01 21:25
I am trying to create an email address as in the Python doc example 
https://docs.python.org/3/library/email-examples.html

The example does not work as given on the page.

I tried Python 3.4rc1 and the 3.5 compiled from source on Ubuntu 12.

I found two possible reasons:

1) Python bug in headerregistry.py
The string resulting from the command below contains extra quotes:

str(Address('Foo Example', 'foo@example.com'))
--> 'Foo Example <"foo@example.com">'


2) Documentation bug

The documentation of headerregistry.Address states:

"username and domain may be specified together by using 
the addr_spec keyword *instead of* the username and domain keywords"

However, this is inconsistent with example 19.1.14.1. on
https://docs.python.org/3/library/email-examples.html

Attached are two tests that reproduce the situation.
The first test below fails but the second passes.

Conclusion:
In my opinion, it is more intuitive if the following would work as well:
Address('Foo Example', 'foo@example.com')
msg228153 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-10-02 03:19
That example is wrong, but that fact weighs heavily in favor of the idea that the "natural" way to write it is the way it is in the example.

Since this part of the email api is still provisional, I propose we change the signature of Address to be:

  Address(display_name='', addr_spec=None, *, username='', domain='')

and make it a ValueError to specify both addr_spec and one or both of username and domain.  For 3.5 I'd just make that change, but for 3.4 I'd make a backward compatibility check and deprecation warning looking for an '@' in the second argument and treat it as username if there's no @ and an addr_spec if there is.
History
Date User Action Args
2022-04-11 14:58:08adminsetgithub: 66725
2014-10-02 03:20:00r.david.murraysetmessages: + msg228153
2014-10-01 21:25:24krothercreate