[Python-Dev] [Email-SIG] headers api for email package

Chris Withers chris at simplistix.co.uk
Fri May 1 19:18:35 CEST 2009


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


More information about the Python-Dev mailing list