So we have these address objects. Currently their string value is the "decoded" value, which means the content from the source is preserved except that (when I get it working!) encoded words and IDNA are decoded.
As reported in the blog post, I've currently added a 'reformatted' attribute to give access to the value formatted according to RFC rules (but currently it isn't handling re-encoding). So, the question is, what do we want the API to ultimately be? I'm thinking that the string value should be the "idealized" value, which would mean we decode it fully and make it RFC conformant where that makes sense (minimal quoting, removal of spaces around dots in local parts, etc). We'll also want a way to get the wire format version of the address out (properly encoded to ASCII). And of course the application may want access to the 'source' value that was parsed to create the Address object. I'm thinking that version should probably be a strict substring of the source attribute of the header the address belongs to. Thoughts? -- R. David Murray http://www.bitdance.com _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
