| msg12620 - (view) |
Author: John Goerzen (jgoerzen) |
Date: 2002-10-07 14:53 |
| 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 |
|
|
| msg12621 - (view) |
Author: Piers Lauder (pierslauder) *  |
Date: 2002-10-11 11:28 |
| 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. |
|
|
| msg12622 - (view) |
Author: John Goerzen (jgoerzen) |
Date: 2002-10-15 18:21 |
| 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. |
|
|
| msg12623 - (view) |
Author: Piers Lauder (pierslauder) * |
Date: 2002-10-16 06:24 |
| 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. |
|
|
| msg12624 - (view) |
Author: John Goerzen (jgoerzen) |
Date: 2002-10-16 17:02 |
| 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. |
|
|
| msg12625 - (view) |
Author: Piers Lauder (pierslauder) * |
Date: 2002-10-16 22:30 |
| 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. |
|
|
| msg12626 - (view) |
Author: Piers Lauder (pierslauder) * |
Date: 2002-11-22 05:56 |
| 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. |
|
|