Re: fixing the current email module

On Oct 9, 2009, at 2:59 PM, Glenn Linderman wrote:

> It would be good though to have standardized terms for easier  
> communication.  Maybe as they are chosen, they could be added to  
> that Wiki RDM set up?

I like raw, transfer-decoded, decoded (or maybe fully-decoded).  As  
I've mentioned before, I don't think the Message or Header APIs need  
to directly support transfer-decoded.

> Separate APIs would be clearer, but for compatibility,  
> should .get_payload() be retained, with the flag?

No.  It was a mistake that should be taken out back and shot.

I would proposal a radical suggestion: we treat backward compatibility  
the way Python 3 did.  Nice to keep, but we can throw it over the side  
in order to fix the warts.  We'll worry about migration strategy later.

Aside: I would really like to have a much more @property based API  
where appropriate.  E.g. Message.get_content_type() would be  
Message.content_type.  And in this case we'd probably have  
message.payload_bytes or some such.  Decoding may require additional  
parameters so it will probably be a method.

> Sure, a registration system is fine.   It could work for any type  
> that has a method that can be registered, that accepts a binary BLOB  
> and returns an appropriate typed and functioning object that can  
> manipulate that type.  That would mean that the application would  
> have to make all the registration calls up front, instead of making  
> the API calls when the objects are retrieved.  Basically, if the  
> email package doesn't have a registration system that the  
> application can use, the application has to invent its own, so this  
> is work that could benefit all applications.

I'm sure there will be lots of default content-types registered, and  
there ought to be a "default" or fallback converter that can be  
overridden.  It should also be possible for third party extensions to  
add additional converters.  Models for this would be timzeone  
additions for datetime, and codecs.

> Actually, although it is not common practice to have encodings other  
> than the RFC defined base64 and quoted-printable, a registration  
> system for converting from #1 to #3, with appropriate defaults for  
> base64, quoted-printable, binary, 7bit, 8bit, would be appropriate,

That makes sense.

-Barry