[Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 15 Oct 2002 11:21:41 -0700
Bugs item #619732, was opened at 2002-10-07 09:53
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fails with literals in LIST resp
Initial Comment:
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
----------------------------------------------------------------------
>Comment By: John Goerzen (jgoerzen)
Date: 2002-10-15 13:21
Message:
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.
----------------------------------------------------------------------
Comment By: Piers Lauder (pierslauder)
Date: 2002-10-11 06:28
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470