[PATCH 04/13] Update to match semantics of new imaplib2
glasse at cs.rpi.edu
Mon Feb 7 18:54:19 GMT 2011
On 02/07/2011 07:12 AM, Sebastian Spaeth wrote:
> On Sun, 6 Feb 2011 11:58:58 -0500, Ethan Glasser-Camp<ethan at betacantrips.com> wrote:
>> The biggest change here is that imapobj.untagged_responses is no
>> longer a dictionary, but a list. To access it, I use the semi-private
>> _get_untagged_response method.
>> diff --git a/offlineimap/folder/IMAP.py b/offlineimap/folder/IMAP.py
>> index db1bdae..2c6ced7 100644
>> @@ -85,14 +85,14 @@ class IMAPFolder(BaseFolder):
>> imapobj = self.imapserver.acquireconnection()
>> # Primes untagged_responses
>> - imapobj.select(self.getfullname(), readonly = 1, force = 1)
>> + imaptype, imapdata = imapobj.select(self.getfullname(), readonly = 1, force = 1)
>> # 1. Some mail servers do not return an EXISTS response
>> # if the folder is empty. 2. ZIMBRA servers can return
>> # multiple EXISTS replies in the form 500, 1000, 1500,
>> # 1623 so check for potentially multiple replies.
>> maxmsgid = 0
>> - for msgid in imapobj.untagged_responses['EXISTS']:
>> + for msgid in imapdata:
>> maxmsgid = max(long(msgid), maxmsgid)
>> except KeyError:
>> return True
> Careful here, are we really sure that we are doing the right thing here
> (and analogue in the quickchanged function)? There are 3 possible return
> scenarioes here (ignoring the "BAD" reply for a moment which we should
> have protected against anyway):
> 1) Return exactly one "EXISTS" reply. Everything is fine.
> 2) Don't return any EXISTS when the folder is empty (as some servers are
> doing per comment). Previously the KeyError exception would have
> handled that. Now, we can never trigger the KeyError case, so that
> one has become useless. (but it seems we would set maxmsgid to 0, so
> we should be fine with regard to what we return. Do away with the
> KeyError exception here?
> 3) Return multiple EXISTS messages, will the imaplib2 code return all of
> them or only one? imaplib2 does:
> typ, dat = self._untagged_response(typ, [None], 'EXISTS')
> in select(). Will that return a list of multiple EXISTS values if we
> get them? Perhaps it is, but I am not sure.
Hmm, good question. It looks to me like _untagged_response returns a
list no matter what. If there's something in self.untagged_responses for
the command, we return that. If not, we return [None].
untagged_responses is generally populated by _append_untagged(), which
either inserts an element of [name, [result]] if none exists, or adds a
result to an existing list otherwise. So if we get multiple EXISTS, I'm
pretty sure we'll get them as a list.
But in the [None] case, I think we'll crash, since long(None) throws an
exception. So I guess I better remove the KeyError handling and replace
it with a check for None.
More information about the OfflineIMAP-project