Hello,

imaplib is behaving weirdly when a LIST response
contains literals -- the {25} sort of syntax.

I have encountered a server in the wild that returns
the folder name part of the response as a literal.

imaplib returns a different sort of result for the two
cases.

Consider this snippet from the imaplib debug log from a
LIST response:

DEBUG[imap]:   30:09.81 untagged_responses[LIST] =>
['() "\\\\" Admin', ('() "\\\\" {19}',
'Admin\\CamillaHansen')

That is:

result[0] = '() "\\\\" Admin'
result[1] = ('() "\\\\" {19}', 'Admin\\CamillaHansen')

Yes, result[0] is a string, and result[1] is a *tuple*!
 And moreover, the tuple even contains the {19}.  This
is silly.  Both are presenting the same data.  Both
should be returned the same way -- possibly as a tuple
to start with.  There is no reason that the client
progrma should have to strip out the {19}, nor that it
should have to check whether the data being returned is
a string or a tuple.  imaplib should do all the
necessary processing internally.

-- John

Logged In: YES 
user_id=196212

Certainly the wrong behaviour!

In order to nail down the source of the problem, would you
kindly
run "imaplib.py -d5 ..." in a way that demontrates the bug
and email me with the entire output? (Send it to
<piers@communitysolutions.com.au>)

That should make clear why the code that deals with the
{nnn} form isn't picking this up.

Thanks.

Logged In: YES 
user_id=491567

I am attaching a full logfile from OfflineIMAP 3.99.1  that
demonstrates this problem.  It uses imaplib with Debug = 5.

Logged In: YES 
user_id=196212

Thanks for the log.

The behaviour you are seeing is the correct one.

If the response to a command returns a tuple instead of a
string, then the tuple is in the form (head, data) - ie: in
the same format as the response from a FETCH command. So,
one needs to check for a tuple in the response, and if so,
find the data in the second element of it.

The philosophy of this module is that it always returns all
the data returned by the server without processing it.

I think the documentation is less than clear on this point
so I'll beef it up.

Logged In: YES 
user_id=491567

I disagree.

First of all, I can see exactly zero rationale for forcing
the implementing software to:

1. Filter out the empty strings -- what exactly is the point
of having those in the returned value anyway?

2. Convert bracketed data separately.  imaplib handles this
for us for message bodies, why not for LIST results?  This
is inconsistent.

3. Check whether it's received a string or tuple, and handle
it differently.

Given all this work, imaplib is not providing any benefit
over speaking IMAP directly.  That defeats the whole purpose
of having the library available in the first place.

Logged In: YES 
user_id=196212

Unfortunately, changing this aspect of imaplib would break
all existing software that uses it.

You should treat imaplib as a low-level module, and consider
writing a wrapper class that implememts the behaviour you
wish to see.

Then submit the wrapper class for inclusion to the imaplib
module.
That way, people can migrate to the new interface when/if
they wish.

Logged In: YES 
user_id=196212

As John hasn't replied to my last comment, I'll take that to
mean no disagreement, and mark this item closed.

I've updated the documentation to emphasise the form of the
results returned by commands.