At 03:38 +0900 04/14/2009, Stephen J. Turnbull wrote: >Tony Nelson writes: > > > OK, Header instances could have a .useful field that returned the useful > > data in all instances. But in any case, the email package should guide > > users in the correct usage, rather than leaving every choice seeming equal, > > when only one choice is correct. > >What do you mean by "only one choice is correct?" For example, a >Destination field might be used for presentation (in which case the >display name are needed), or to compose a list of recipients (when >thjey should be discarded). Some applications might prefer to receive >the combination as the original string (although that often is not >valid RFC-any), others might prefer it parsed into a pair of display >name and mailbox. ...
Assuming that by "Destination" you mean a class of Address header fields, as there is no Destionation: header field, such header fields contain addresses, which can be considered to contain (as the email package does) a list of (name, email address) pairs, or, at a lower level, to also have Comments, there is indeed only one correct choice, which is the one the email package currently provides the diligent user. I wish it to be the one obvious choice, so that less study is needed to properly use the email package. Any use that wishes to discard the email addresses in favor of the friendly names can do so most easily from the parsed [(name, address)], not from the bytes. Parsing Address header fields is hard. Note that Address headers are not Text, as only certain tokens -- not part of the email addresses -- can be RFC 2047-encoded. -- ____________________________________________________________________ TonyN.:' <mailto:tonynel...@georgeanelson.com> ' <http://www.georgeanelson.com/> _______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
