This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Newer reply format for imap commands in imaplib.py
Type: enhancement Stage: test needed
Components: Library (Lib) Versions: Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: eric.smith, ntai, r.david.murray
Priority: normal Keywords: patch

Created on 2007-06-12 06:48 by ntai, last changed 2022-04-11 14:56 by admin.

Files
File name Uploaded Description Edit
foo.txt ntai, 2007-06-12 06:48 A proposal request for imaplib.py enhancement
Messages (5)
msg55140 - (view) Author: Naoyuki Tai (ntai) Date: 2007-06-12 06:48
If the fetch command does not contain literal, the result is

[ '1 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)',
 '2 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)']

If the fetch command contains literal, the result is

[ ('1 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435', 'header literal'),
 ')',
 ('2 (FLAGS (\\Seen) UID 1 RFC822.SIZE 26435', 'header literal'),
 ')']

First off, the number of elements in the reply becomes twice of non-literal fetch command.

Secondly, to parse the attribute string like "(FLAGS (\\Seen) UID 1 RFC822.SIZE 26435)" , one must check the first and last character to be '(' and ')' for the correctness of reply.

With the second type of reply / the reply with literal,  the reply string needs to be reconstructed out of the first element of tuple in an element, the subsequent element by appending them.

If the number of elements in the reply matches with the number of mails fetched, I can deal with the reply a lot easier.

As the shape of fetch command output is very different depending on literal, the use of fetch() is too hard for its good.

Therefore, I propose the new response format.
fetch_status, [ entry1, entry2, entry3, ... ]

And each entry is
[entry-reply]
or
[entry-reply, [literals]]

This allows that you can get to the entry reply uniformly regardless of whether or not the query of fetch with or without literal response.

Since the proposed response format is not compatible with existing format, additional proposal is to let the user of imaplib.py to designate the response format, as existing format as 1, and the new format as 2.

I have attached a patch for the proposed change.
msg55141 - (view) Author: Naoyuki Tai (ntai) Date: 2007-06-12 07:06
I overlooked that IMAP4_SSL needs the same enhancement. IMAP4_SSL's constructor should look like as follows.

    def __init__(self, host = '', port = IMAP4_SSL_PORT, keyfile = None, certfile = None, response_format = 1):
        self.keyfile = keyfile
        self.certfile = certfile
        IMAP4.__init__(self, host, port, response_format)
msg116689 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-09-17 17:33
Is there any interest in the change proposed here?  If not I'll close in a few weeks time.  Note the patch does not include doc or unit test changes.
msg116692 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-09-17 17:36
I'm not sure what "fetch command does not contain literal" means. If the OP can clarify, I'd be interested in this issue.
msg116698 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-17 18:14
Someday I intend to pay a constructive visit to imaplib, so yes please leave this open.
History
Date User Action Args
2022-04-11 14:56:24adminsetgithub: 45085
2014-02-03 19:43:31BreamoreBoysetnosy: - BreamoreBoy
2010-09-17 18:15:01r.david.murraysetnosy: + r.david.murray
messages: + msg116698
2010-09-17 17:36:15eric.smithsetstatus: pending -> open
nosy: + eric.smith
messages: + msg116692

2010-09-17 17:33:18BreamoreBoysetstatus: open -> pending
nosy: + BreamoreBoy
messages: + msg116689

2009-03-31 01:19:28ajaksu2setkeywords: + patch
stage: test needed
versions: + Python 2.7
2007-06-12 06:48:20ntaicreate