[issue1409460] email.Utils.parseaddr() gives arcane result

Éric Araujo added the comment: Copied my inquiry and part of your reply in #9286. -- stage: -> committed/rejected ___ Python tracker ___ _

[issue1409460] email.Utils.parseaddr() gives arcane result

Éric Araujo 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 goin

[issue1409460] email.Utils.parseaddr() gives arcane result

Mark Sapiro 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

[issue1409460] email.Utils.parseaddr() gives arcane result

Éric Araujo 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 twe

[issue1409460] email.Utils.parseaddr() gives arcane result

Daniel Diniz 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