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.