[Email-SIG] fixing the current email module
Barry Warsaw
barry at python.org
Mon Oct 12 22:41:48 CEST 2009
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/email-sig/attachments/20091012/36621696/attachment.pgp>
More information about the Email-SIG
mailing list