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.

Author r.david.murray
Recipients Anthony.Kong, Juhana.Jauhiainen, alfmel, barry, catalin.iacob, geoffreyspear, giampaolo.rodola, hynek, josiah.carlson, maker, r.david.murray, richard, tshepang
Date 2012-03-11.15:58:45
SpamBayes Score 4.9732274e-11
Marked as misclassified No
Message-id <1331481527.96.0.188985312191.issue8739@psf.upfronthosting.co.za>
In-reply-to
Content
Juhana: thanks for the patch.  I see an issue with it, though.  What if the email address is something like JOHN.SIZER@example.com?

My thought is that there are two ways to handle this.  Either we do a full RFC address parse in __getaddr and have it return the remainder of the line, or we parse from the right hand side looking for keword=value elements (which if I remember the RFC right have a pretty constrained syntax).  

Ideally I'd like to see a general parsing solution so we can handle other parameters in the future easily.  So perhaps a function like

  _getkeywords(arg) -> (arg, kwdict)

that parses the keywords off from the right and returns them in a dict, along with whatever non-keyword argument text is left.

The other path, parsing the address fully, could theoretically use the parseaddr utility from the email package, but I'm not sure if it will return the endpoint of an address embedded in a longer string.
History
Date User Action Args
2012-03-11 15:58:48r.david.murraysetrecipients: + r.david.murray, barry, richard, giampaolo.rodola, josiah.carlson, maker, alfmel, catalin.iacob, tshepang, geoffreyspear, Anthony.Kong, hynek, Juhana.Jauhiainen
2012-03-11 15:58:47r.david.murraysetmessageid: <1331481527.96.0.188985312191.issue8739@psf.upfronthosting.co.za>
2012-03-11 15:58:45r.david.murraylinkissue8739 messages
2012-03-11 15:58:45r.david.murraycreate