[Email-SIG] Non-string headers

[Barry Warsaw]

On Tue, 2004-04-20 at 07:18, Oleg Broytmann wrote:

>    Is it a bug or a feature? I personnaly thing it is a feature, but a
> colleague of mine initiated a discussion trying to convince me this is a bug in
> email and shoud be fixed by calling str() on every header's name (yes, name)
> and value.

Actually, all header names are converted to strings, via modulo
operator.  The Generator will basically use print>> to output the value
of the header, but it does a couple of conditionals first (whether
there's any wrapping, if the value is a Header or an 8-bit string).

So it wouldn't be /difficult/ I think to add stringification of other
values, I'm just not sure it's a good idea.  That you get this specific
error is mostly just an accident of implementation than a designed
feature.

Rather than relax the values that a header can have, I'm inclined to
tighten them.  The rule could be that the header value must be a Unicode
string, or an instance providing a particular interface (which by
default Headers would implement).  This way, raw 8-bit strings would be
out (mixing 8-bit and Unicodes is evil anyway :), and you could always
wrap your values in an instance that supported the given interface. 
Accepting Unicodes would be a convenience for the simple case.

Then Message.add_header() and friends would throw a TypeError early if
the value didn't conform.

Comments?
-Barry