On 25 July 2011 23:39, Maxim Khitrov <max@mxcrypt.com> wrote:
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.
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