for the email package. The former is now just a shell project that
has some extra files for packaging for independent use (e.g. setup.py
and README).
Added a compatibility layer so that the same API can be used in Python
2.1 and 2.2/2.3 with the major differences shuffled off into helper
modules (_compat21.py and _compat22.py).
Also bumped the package version number to 2.0.3 for some fixes to be
checked in momentarily.
double call to AddressList.getaddrlist(), and /that/ always returns an
empty list for the second and subsequent calls.
Instead, instantiate an AddressList directly, and get the parsed
addresses out of the addresslist attribute.
non-us-ascii character sets in headers and bodies. Some API changes
(with DeprecationWarnings for the old APIs). Better RFC-compliant
implementations of base64 and quoted-printable.
Updated test cases. Documentation updates to follow (after I finish
writing them ;).
incorrect for "uneven" timezones. This algorithm should work for even
timezones (e.g. America/New_York) and uneven timezones (e.g.
Australia/Adelaide and America/St_Johns).
Closes SF bug #483231.
rfc822.py. The old rfc822.formatdate() produced date strings using
obsolete syntax. The new version produces the preferred RFC 2822
dates.
Also, an optional argument `localtime' is added, which if true,
produces a date relative to the local timezone, with daylight savings
time properly taken into account.
the separating semi-colon shows up on a continuation line (legal, but
weird).
Bug reported and fixed by Matthew Cowles. Test case and sample email
included.
_handle_multipart(): If there is an epilogue and the epilogue does
not itself start with a newline, add a newline before writing the
epilogue. Closes SF bug #472481.
_split_header(): Split on folding whitespace if the attempt to split
on semi-colons failed.
_split_header(): Patch by Matthew Cowles for fixing SF bug # 471918,
Generator splitting long headers.
failobj, and when getting the subtype use 'plain' as the failobj.
text/plain is supposed to be the default if the message contains no
Content-Type: header.
headers. It does not parse the body of the message, instead simply
assigning it as a string to the container's payload. This can be much
faster when you're only interested in a message's header.
Also, add a clause to the big-if to handle message/delivery-status
content types. These create a message with subparts that are
Message instances, which best represent the header blocks of this
content type.
get_type(): Use a compiled regular expression, which can be shared.
_get_params_preserve(): A helper method which extracts the header's
parameter list preserving value quoting. I'm not sure that this
needs to be a public method. It's necessary because we want
get_param() and friends to return the unquoted parameter value,
however we want the quote-preserved form for set_boundary().
get_params(), get_param(), set_boundary(): Implement in terms of
_get_params_preserve().
walk(): Yield ourself first, then recurse over our subparts (if any).
Text.py and class Text => MIMEText.py and MIMEText
MessageRFC822.py and class MessageRFC822 => MIMEMessage.py and MIMEMessage
These are renamed so as to be more consistent; these are MIME specific
derived classes for when creating the object model out of whole cloth.
_handle_text(): If the payload is None, then just return (i.e. don't
write anything). Subparts of message/delivery-status types
will have this property since they are just blocks of headers.
Also, when raising the TypeError, include the type of the
payload in the error message.
_handle_multipart(), _handle_message(): When creating a clone of self,
pass in our _mangle_from_ and maxheaderlen flags so the clone
has the same behavior.
_handle_message_delivery_status(): New method to do the proper
printing of message/delivery-status type messages. These have
to be handled differently than other message/* types because
their payloads are subparts containing just blocks of headers.
In class DecodedGenerator:
_dispatch(): Skip over multipart/* messages since we don't care
about them, and don't want the non-text format to appear in
the printed results.
<http://sf.net/projects/mimelib>. There /are/ API differences between
mimelib and email, but most of the implementations are shared (except
where cool Py2.2 stuff like generators are used).
Barry Warsaw
Greg Ward
Tim Peters