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

[Michael Foord]

On 25 July 2011 23:39, Maxim Khitrov <max at mxcrypt.com> wrote:

> On Mon, Jul 25, 2011 at 4:27 PM, Michael Foord <fuzzyman at gmail.com> wrote:
> >
> >
> > On 25 July 2011 20:38, Maxim Khitrov <max at mxcrypt.com> wrote:
> >>
> >> On Mon, Jul 25, 2011 at 3:21 PM, Michael Foord <fuzzyman at gmail.com>
> wrote:
> >> >
> >> >
> >> > On 25 July 2011 02:06, Maxim Khitrov <max at 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.
>
>
Well I'm sure Menno would be interested if you could actually demonstrate
those limitations rather than merely assert that. :-)

(As he implemented to overcome problems with imaplib and that is why people
use it.)

Not that you're necessarily wrong, but I'm skeptical.

Michael


> 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
>



-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110726/fec99f56/attachment.html>