Stephen J. Turnbull wrote:
> > > str(message['Subject'])
> >
> > Yes for unstructured headers like Subject. For structured headers...
> > hmm.
>
> 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:
>
> > > bytes(message['Subject'])
>
> 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
> > > hard!":
>
> -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,
Don't agree...
> > > Message['Subject']='Some text'
>
> 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 :-)
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4