On Mon, Jul 25, 2011 at 4:27 PM, Michael Foord <fuzzyman@gmail.com> wrote:
>
>
> On 25 July 2011 20:38, Maxim Khitrov <max@mxcrypt.com> wrote:
>>
>> On Mon, Jul 25, 2011 at 3:21 PM, Michael Foord <fuzzyman@gmail.com> wrote:
>> >
>> >
>> > On 25 July 2011 02:06, Maxim Khitrov <max@mxcrypt.com> wrote:
>> >>
>> >> Hello python-ideas,
>> >>
>> >> My most recent project lead me down a path that eventually ended up at
>> >> a new implementation of imaplib based on [RFC-3501]. Although I
>> >> started the project by gradually adding functionality to the existing
>> >> IMAP4 library, some of the features that I required simply could not
>> >> be merged in (without breaking everything). As a result, I wrote my
>> >> own version of the library, which incorporates all existing
>> >> functionality of imaplib and includes many of my own improvements.
>> >>
>> >
>> > There is an existing, well tested and widely used, replaced for imaplib
>> > that
>> > I would suggest should be the first for consideration in replacing
>> > imaplib:
>> >
>> > http://imapclient.freshfoo.com/
>> >
>> > (Sorry.)
>> >
>> > All the best,
>> >
>> > Michael Foord
>>
>> I have it beat at the "Python 3 support is in the works" feature ;)
>> Mine doesn't handle 2.x though.
>>
>> In any case, I would not have been able to use IMAPClient for my
>> project, because the requirements were for no dependencies outside of
>> Python 3.2.
>>
>> Do you know if the developers of IMAPClient considered getting it into
>> the standard library? My goal wasn't just to have another IMAP
>> implementation, but something better available as part of Python.
>>
>
>
> I don't think Menno Smitts would object to adding Python 3 support or adding
> IMAPClient to the standard library. His goal was to create something useful
> to overcome what he saw (and evidently you agree) as irreparable brokenness
> in parts of imaplib.
>
> My point is that if there is an existing widely-used and battle-tested
> alternative, we would be wise to look at that first.

Agreed. However, I just took a look through IMAPClient source code and
have to correct you on your original assertion. IMAPClient is not a
replacement for imaplib, but a wrapper around it.

The author went down the same road that I originally started out on.
He added a parser, a UTF-7 codec, and changed the overall interface to
be more user-friendly. All good improvements, but at the core,
IMAPClient relies entirely on imaplib, and thus inherits most of its
design flaws.

With the exception of the first and fifth bullet points in my README
file (server response parser & UTF-7 mailbox name codec,
respectively), all others apply equally to IMAPClient. For that
reason, I would recommend against incorporating it into the standard
library.

My opinion on the matter is certainly biased, so I would welcome a
review of both libraries by a neutral party familiar with the IMAP
protocol, who could then make a recommendation.

- Max