[ python-Bugs-1409455 ] email.Message.set_payload followed by bad result get_payload
SourceForge.net
noreply at sourceforge.net
Thu Jan 19 00:25:30 CET 2006
Bugs item #1409455, was opened at 2006-01-18 17:09
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Sapiro (msapiro)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Message.set_payload followed by bad result get_payload
Initial Comment:
Under certain circumstances, in particular when charset
is 'iso-8859-1', where msg is an email.Message() instance,
msg.set_payload(text, charset)
'apparently' encodes the text as quoted-printable and
adds a
Content-Transfer-Encoding: quoted-printable
header to msg. I say 'apparently' because if one prints
msg or creates a Generator instance and writes msg to a
file, the message is printed/written as a correct,
quoted-printable encoded message, but
text = msg._payload
or
text = msg.get_payload()
gives the original text, not quoted-printable encoded, and
text = msg.get_payload(decode=True)
gives a quoted-printable decoding of the original text
which is munged if the original text included '=' in
some ways.
This is causing problems in Mailman which are currently
worked around by flagging if the payload was set by
set_payload() and not subsequently 'decoding' in that
case, but it would be better if
set_payload()/get_payload() worked properly.
A script is attached which illustrates the problem.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470
More information about the Python-bugs-list
mailing list