[issue1409460] email.Utils.parseaddr() gives arcane result
Éric Araujo mer...@netwok.org added the comment:
I wonder if this bug should be reopened. This behavior does not seem right to
me:
parsing 'merwok'
expected ('merwok', '')
got ('', 'merwok')
parsing 'merwok w...@rusty'
expected ('', 'w...@rusty')
got ('', 'merwok...@rusty')
(Generated with a twenty-line script just doing a loop and prints, not attached
because boring.)
Are my expectations wrong? I don’t know if a string like “merwok” in my first
example is a legal address in the relevant RFCs, nor do I know if the folding
done in the second example is okay.
For background, the thing I’m trying to achieve is to take a string and parse
it into name and email address, and print a warning if there is no email. It’d
be nice if I could always test for “not parseaddr(s)[1]”, or pass an argument
to the function to get an exception. Maybe I’ll have to restrict my format and
do my own parsing with str.[r]partition.
--
nosy: +merwok, r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1409460
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1409460] email.Utils.parseaddr() gives arcane result
Mark Sapiro m...@msapiro.net added the comment:
parsing 'merwok'
expected ('merwok', '')
got ('', 'merwok')
I think ('', 'merwok') is the correct result. I think most if not all MUAs/MTAs
will interpret an address without an '@', albeit invalid, as a local-part in
the local domain, thus parsing 'merwok' as the address 'merwok' with no real
name is probably the right thing to do with this input. The alternative would
be to return ('', '') indicating failure.
parsing 'merwok w...@rusty'
expected ('', 'w...@rusty')
got ('', 'merwok...@rusty')
Here, I think failure is a more appropriate return.
In any case, I think this is a new bug deserving of a new report. It is not
really relevant to this issue which has to do with nested parentheses.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1409460
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1409460] email.Utils.parseaddr() gives arcane result
Éric Araujo mer...@netwok.org added the comment: Thank you for the reply. The problem is that parseaddr is designed to not fail IIUC, that’s why it may return empty strings. Client code has to check for these values instead of catching an exception—a mere style issue, weren’t it for the second bug. So I’m going to report that separately, and restrict the format in my project so that my code can just use string methods. I think I won’t open a feature request for a parameter to get exceptions, since parseaddr is designed not to. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1409460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1409460] email.Utils.parseaddr() gives arcane result
Éric Araujo mer...@netwok.org added the comment: Copied my inquiry and part of your reply in #9286. -- stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1409460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1409460] email.Utils.parseaddr() gives arcane result
Daniel Diniz aja...@gmail.com added the comment: Fixed in trunk, so issue 1464708 was probably forward ported. -- dependencies: +fixed handling of nested comments in mail addresses nosy: +ajaksu2 resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1409460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
