[issue11216] email.message.Message set_charset does not encode properly?
Shay Rojansky r...@roji.org added the comment: Thanks and no problem for me, the workaround (deleting the header) works just fine. I'm not sure if/when the more general discussion on the package will take place (low-level vs. high-level), I would be interested in following. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11216 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11216] email.message.Message set_charset does not encode properly?
Shay Rojansky r...@roji.org added the comment: Sorry for disappearing, will be following this closer from now on. Thanks for the responses (and the acknowledgement of a problem), David and Steffen. I understand the API design philosophy and the need to allow the production of invalid messages. The main problem point to me is what seems to be an inconsistency in the API: * When constructing a new message/part (i.e. in the constructor), management of the Content-Transfer-Encoding header and responsibility for doing base64 is done by the API. * But when using mutators (set_payload, set_charset), these become the responsibility of the caller, etc. So one aspect of the API is high-level, another low-level. I have no idea whether this was a planned thing in some way, and have a hard time estimating whether modifying the behavior (i.e. making set_payload/set_charset high-level like the constructor) would break apps that depend on the current low-level behavior... One thought though... Another part of the API already allows the user to indicate whether they want low or high level behavior: get_payload accepts the boolean decode flag. Would it not make sense to add a similar encode flag to set_payload? To be complete such a flag could also be added to the constructor. Apart from that, I guess a good doc patch would run along the lines of appending the following to set_charset's description: Note that if a Content-Transfer-Encoding header is already present on the message, it is kept as is and no content transfer encoding is applied to the payload. This can -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11216 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11245] Implementation of IMAP IDLE in imaplib?
New submission from Shay Rojansky r...@roji.org: IMAP IDLE support is not implemented in the current imaplib. A drop-in replacement called imaplib2 exists (), but uses internally managed threads - a heavy solution that is not always appropriate (e.g. when handling many IMAP accounts an asynchronous approach would be more efficient) I am about to start implementation of an asynchronous select()-compatible approach, and was wondering if there has been any discussion over IDLE, any specific reasons it hasn't been implemented and if eventual integration into imaplib would be a desirable thing. Proposed approach: * Addition of a new state 'IDLE' * Addition of an idle() method to class IMAP4, which issues the IDLE command to the server and returns immediately. At this point we enter the IDLE state, in which no normal IMAP commands may be issued. * Users can now select() or poll() the socket as they wish * A method can be called to retrieve any untagged responses (e.g. EXISTS) that have arrived since entering the IDLE state. The function returns immediately and does not modify the state. * To end the IDLE state, the user calls a method (done()?) which resumes the previous state. Would appreciate any sort of feedback... -- components: Library (Lib) messages: 128814 nosy: Shay.Rojansky priority: normal severity: normal status: open title: Implementation of IMAP IDLE in imaplib? type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11216] email.message.Message set_charset does not encode properly?
New submission from Shay Rojansky r...@roji.org:
This may be my misunderstanding of the correct behavior, thanks in advance for
your patience...
The issue happens when calling set_charset (or set_payload charset) after a
Message has already been created and contains a Content-Transfer-Encoding
header. Here's an example:
from email.mime.text import MIMEText
part = MIMEText('Some stuff aéàçça', 'plain', 'utf-8')
print part
From nobody Mon Feb 14 19:57:17 2011
Content-Type: text/plain; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: base64
U29tZSBzdHVmZiBhw6nDoMOnw6dh
part.set_payload('Other stuff aéàçça', 'utf-8')
print part
From nobody Mon Feb 14 19:57:25 2011
Content-Type: text/plain; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Other stuff aéàçça
del part['Content-Transfer-Encoding']
part.set_payload('Still some other stuff aéàçça', 'utf-8')
print part
From nobody Mon Feb 14 19:57:40 2011
Content-Type: text/plain; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: base64
U3RpbGwgc29tZSBvdGhlciBzdHVmZiBhw6nDoMOnw6dh
First the text part is created with charset UTF-8, a dump shows a
properly-encoded base64 UTF-8 part.
Then an attempt is made to modify the payload. The set_charset documentation
clearly states that the message will be properly encoded/converted, but we get
a malformed part with Content-Transfer-Endogin=base64 but without a
base64-encoded payload.
Finally, as a workaround, I delete the Content-Transfer-Encoding header and try
again, at which point the new payload is properly encoded.
Again, I'm sure there are reasons for this behavior, which nevertheless seems
like a bug to me (shouldn't set_charset perform base64 and change the
Content-Transfer-Encoding if necessary regardless of previous headers?). Maybe
a documentation update would help people with this.
Thank you very much!
--
components: Library (Lib)
messages: 128573
nosy: Shay.Rojansky
priority: normal
severity: normal
status: open
title: email.message.Message set_charset does not encode properly?
type: behavior
versions: Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11216
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11216] email.message.Message set_charset does not encode properly?
Shay Rojansky r...@roji.org added the comment: Sorry, the print part below doesn't work on Python3 (I'm back in 2.6), but I see the same trouble by using part.__str__() -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11216 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
