R. David Murray added the comment:
Because the RFCs are defined only for ascii. Non-ascii in RFC 2822 addresses
is an RFC violation. In python2 non-ascii would usually round-trip through
these functions, but again that was an accident.
If you'd like to propose a doc clarification that
skreft added the comment:
@r.david.murray where do you see that those functions are only defined for
ascii? There's nothing in the online docs stating that and furthermore
`formataddr` has supported non-ascii names since version 3.3. RFC 2822 is
however mentioned in the docstrings.
The
R. David Murray added the comment:
Thanks for the report, but parseaddr and formataddr are defined *only* for
ASCII. In the port to python3, parseaddr sort-of-maybe-sometimes does the
naively expected thing with non-ascii, but that's just an accident. We could
have added a check for
Rémi Lapeyre added the comment:
This is indeed an issue with formataddr, it expects the input to be ascii
encoded as RFC 2822 requires.
Email is much more complicated though and has been internationalized, a summary
of this work is available at
New submission from skreft :
The docs
(https://docs.python.org/3/library/email.util.html#email.utils.formataddr) say
that formataddr is the inverse of parseaddr, however non-ascii email addresses
are treated differently in both methods.
parseaddr will return non-ascci addresses, whereas
