[Email-SIG] fixing the current email module

[Stephen J. Turnbull]

Barry Warsaw writes:

 > 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.

+1

 > Aside: I would really like to have a much more @property based API  
 > where appropriate.

+1

 > 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.

Maybe, but in general those parameters can be deduced from the
metadata.  If we can use those defaults often enough, then the
default-decoded version can be a property too.

We would have to provide alternatives, though.  I've seen Shift JIS
encoded Japanese labelled "ISO-2022-JP", and apparently many Japanese
MUAs actually decode that to Japanese!  Not suggesting that we should
do the same, but probably the generic function that is used to decode
should be exposed as a method so that clients who encounter such
nonsense can deal with it, and override any of the metadata.