[Python-ideas] New imaplib implementation for Python 3.2+ standard library

[Menno Smits]

On 28/07/11 02:35, Maxim Khitrov wrote:

>> It requires too much effort on behalf of the caller. Your example.py
>> highlights how datetimes are returned as strings that need to be
>> converted to real datetimes and FETCH response keys need to be
>> uppercased to ensure consistency. The need to jump through the same
>> non-trivial hoops each time I used imaplib was one of the frustrations
>> that led to the creation of IMAPClient. Please consider having
>> imaplib2
>> do a little more work so that every user doesn't have to.
> 
> Part of this will be addressed by the higher-level interface that I'm
> currently working on. As for imaplib2, there are two reasons why I
> decided not to do any sort of automatic normalization of the responses
> (with the exception of CAPABILITY):
...
> So basically, I think that in a low-level library such as this, it
> should be the caller's decision whether an INTERNALDATE value is
> converted to Unix time (or some other format), or if the FETCH
> response keys are changed to upper case. I'm happy to provide
> additional utility functions for such conversions, but trying to
> handle these things automatically could be a source of many additional
> bugs. Think about the separation between zlib and gzip, or binascii
> and base64 modules. My library is the low-level interface and I'm
> working on something that will be easier to use at the cost of some
> control.

Fair enough. If you're planning a higher-level interface and helper
functions that means less repeated work for each user of imaplib2 then
that's great.

>> Similarly, UID support could be better. IMAPClient has a boolean
>> attribute which lets you select whether you want UIDs to be
>> transparently used for future commands. Having to specify whether you
>> want UID support enabled on each call is a little clumsy. It's
>> unlikely
>> that a user of imaplib2 would want to toggle between using UIDs and
>> not
>> on every call.
> 
> I have to disagree with you here. The application that I wrote this
> library for does depend on the ability to run UID and regular FETCH
> commands in the same connection. I was actually very surprised to see
> that IMAPClient requires you pick one or the other at creation time.

That's not quite right. UID selection can be set at creation time but
also be changed at any point by using the use_uid attribute.

> In some applications you may need to discover and use the
> relationships between SNs and UIDs, or use a command like UID EXPUNGE
> (from UIDPLUS extension) and a regular EXPUNGE in the same session. I
> think that you do have to let the user make this decision on a
> per-command basis.

I think that having to pass the flag on each call is a little awkward
but that's a minor issue really. Maybe you could allow the user to
specify a default value to use it's not specified for a given command?

> My library does need more testing. Although I tried to follow the
> robustness principle (be conservative in what you send; be liberal in
> what you accept) when writing the command generator and response
> parser, there probably are some bugs remaining, but hopefully not
> many.
> 
> Which IMAP servers do you test against and how did you go about
> getting the test accounts?

I regularly test against: Gmail, Fastmail.fm (a Cyrus variant), vanilla
Cyrus, Dovecot, Courier and MS Exchange. Gmail and Fastmail have free
accounts and I run the other test servers myself except for the Exchange
server which is at my employer.

>> [1] - Are you aware there's already another project with the same
>> name?
>> http://www.janeelix.com/piers/python/imaplib2.html
> 
> Hmm... I probably should have tried searching before using that name.
> I'm happy to go with something else, since my library is not in
> wide-spread use right now. Would suggesting imaplib3 for stdlib be a
> bit confusing? :/

Possibly! I'm not sure of a better name though. IMAPClient was the best
I could come up with and that conflicts with a Perl package of the same
name and functionality :)

All the best,
Menno