Stephen J. Turnbull wrote:
Yes for unstructured headers like Subject. For structured headers...
Well, suppose we get really radical here. People see email as (rich-)text. So ... message['Subject'] returns an object, partly to be consistent with more complex headers' APIs, but partly to remind us that nothing in email is as simple as it seems. Now, str(message['Subject']) is really for presentation to the user, right? OK, so let's make it a presentation function! Decode the MIME-words, optionally unfold folded lines, optionally compress spaces, etc. This by default returns the subject field as a single, possibly quite long, line. Then a higher-level API can rewrap it, add fonts etc, for fancy presentation. This also suggests that we don't the field tag (ie, "Subject") to be part of this value.
Of course a really smart higher-level API would access structured headers based on their structure, not on the one-size-fits-all str() conversion.
All sounds good to me.
Then MTAs see email as a string of octets. So guess what:
gives wire format. Yow! I think I'm just joking. Right?
Why? That also sounds fine to me and "feels right"...
Where you just want "a damned valid email and stop
making my life
-1 I mean, yeah, Brother, I feel your pain but it just isn't that easy. If that were feasible, it would be criminal to have a .set_header() method at all! In fact,
is going to (a) need to take only unicodes, or (b) raise Exceptions at the slightest provocation when handed bytes.
It should only take unicodes and bitch profusely about anything else.
And things only get worse if you try to provide this interface for say "From" (let alone "Content-Type"). Is it really worth doing the mapping interface if it's only usable with free-form headers (ie, only Subject among the commonly used headers)?
Sure, for other headers it might not accept unicodes...
How do you distinguish "raw" bytes from "encoded bytes"? __setitem__() shouldn't accept bytes at all.
Right on :-)
-- Simplistix - Content Management, Zope & Python Consulting