IMAP Literals are a tricky subject.  Currently, if IMAP returns:

* text text text {5}\r\n
12345more text

imaplib will return 2 data items:
[("text text text {5}", '12345'), "more text"]

This forces users of imaplib to then parse out and remove the '{5}' from
the first part of the tuple before appending the literal string.  It
would be nice to have imaplib strip the '{size}' portion of the string
in the first part of the tuple, so that the return value would be:
[("text text text ", '12345'), "more text"]

Though, because this entire response from the IMAP server should be
interpreted as a single line, it would be even better to return a
response such that 'data' is:
[(("text text text ", '12345'), "more text")]

a.k.a., a single 'data' item (only one IMAP response per data item) that
contains either a string or a tuple.  The tuple will contain either more
tuples and/or more strings.  Each sub-tuple here would contain two
strings, text, and the IMAP Literal String.

This would make parsing the responses from imaplib much more simple.  It
demarks obviously where IMAP Literal Strings are, and doesn't require
additional string parsing on the side of the imaplib user.

Thanks!

While IMAP is very much a live protocol, I do not know that any of the currently active core developers know much about it. Imaplib is based on the obsolete RFC2060 of Dev 1996, superseded by 3501 in March 2003, with 6 later updates. (I just found all this out to respond here.)

It is written in Python. If you take a look at the code, you will see that 7 people have contributed additions after the initial writing (and others may have contributed unlisted patches). Feel free to submit another by yourself.

that change would require a new interface. 
Since there is a drop-in threaded implementation of imaplib (imaplib2) and a higher-level wrapper (imapclient) which uses imaplib2 if available and falls back to imaplib if not, I think it is better to fully revise the interface, possibly with the planned eventloop in mind.

Since I wrote this, a new method has been added to the IMAP4 class (starttls(ssl_context=None), 3.2) and a new parameter to the IMAP_SSL subclass initialization (3.3). So the module is not dead. 

Thomas is correct that a new method or, more likely, module utility function would be needed to do any transformation of IMAP4 output. Anyone is free now to write their own function. So any proposal would need an argument that there is standard transform that would be useful and used by multiple people.

In the absence of a concrete proposal, and considering the possibility of a new protocal, I am closing this at least for now. Brandon, if you post either a patch or just code for a new function and an explanation of how to use it, and are prepared to defend it, you may reopen.  You might do better to post to python-list or python-idea to see if there are any other users that would like the same transformation you want.