[Email-SIG] API for Header objects [was: Dropping bytes "support" in json]

Tony Nelson tonynelson at georgeanelson.com
Thu Apr 16 02:39:52 CEST 2009


At 17:47 +0900 04/15/2009, Stephen J. Turnbull wrote:
>Tony Nelson writes:
>
> > Well, msg['To'] would return a list (or tuple) of addresses (which
> > are tuples), so msg['To'][0] would return the first such address,
> > if any.  No converter required.
>
>How do you propose to spell
>
>    msg['To'].split_addresses()[0]
>
>where the split_addresses method returns a list of addresses in their
>original form?  And is it really worth losing the consistency that
>str(msg[tag]) and bytes(msg[tag]) (especially the latter) do something
>more or less useful regardless of whether 'tag' names a structured
>field or a text field?

I don't want there to be any "str(msg['tag'])" or "bytes(msg['tag'])" at
all, so there would be no loss of consistency.  Messages need flattening to
bytes, but there is no use for converting individual header fields into
bytes or strings, outside of a message.  Some header field data /is/
strings, some is lists of address pairs, and so on.  If the data for a
header field is not properly a string, a means to get it as one is wrong.

I can't imagine that .split_addresses() would provide anything in its
original form.  I'd certainly want it to split something into a list or
tuple.  As individual addresses in an Address header field are accessed
from the list returned by "msg['To']" (or other Address header field name),
there is no need to "split" them any more.


>As I wrote elsewhere, I don't *know* that such features will be useful
>or practically implementable, but I do think what you're suggesting is
>premature and overly restrictive.  Especially since we are pretty sure
>(due to the desire for idempotency) that internally msg['To'] will
>*not* be a sequence of addresses parsed into display name and mailbox.

All the grotty internals of Heaer objects would be accessible by fetching
the Header object with "msg.get_header('name')".  "msg[...]" is an
abbreviation for convenience which should not mislead users or be complex
or magical in action.  I want to be able to get and put the proper type of
data for a particular header field, and to be told when I did it wrong,
rather than just get a corrupt message.

Internally, the Header whose .useful attribute is returned by "msg['foo']"
will contain parsed data, referring to parsed tokens.  Flattening those
parsed tokens will produce the original data.  Not a problem at all, simple
to implement, in the most direct way.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:tonynelson at georgeanelson.com>
      '                              <http://www.georgeanelson.com/>


More information about the Email-SIG mailing list