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

[Bill Janssen]

Maxim Khitrov <max at mxcrypt.com> wrote:

> > I tend to think one of the larger missing pieces of imap4lib is the lack
> > of a higher-level interface.  I've used imap4lib for a couple of
> > projects, and I think that if I hadn't already had the experience of
> > implementing my own IMAP server in Python, I wouldn't have done that;
> > I'd have used a package like getmail instead.  There's a lot of
> > experience with IMAP necessary to use imap4lib.
> 
> True, but that's the case with all low-level interfaces. Having used
> imaplib for a while before deciding to write a replacement, I do think
> that building a higher-level interface using my library is
> significantly easier.
> 
> I'm not certain if that interface should be part of the library or a
> separate module, similar to the relationship between zlib and gzip. I
> think the latter makes more sense, because any serious IMAP4 client
> will still need to descend to the protocol level.

There are lots of folks who just need to connect to an IMAP account, and
do something with their mail.  Many many fewer need to write a serious
IMAP4 client.  That's the big problem with the current imap4lib; it just
doesn't work for most of the use cases, because it's too low-level.  So
it doesn't get much use -- more's the pity.

> > Looking at your example.py, that still seems to be the case.  One thing
> > you might consider is implementing a subclass of "mailbox.Mailbox" which
> > provides that missing higher-level interface to IMAP4.
> 
> I've never used the mailbox module before. It looks like it is aimed
> primarily at working with local mail stores, no? I'm not sure if
> that's the right interface to use over the network, but I understand
> your point.
>
> I'll try to write another class on top of my library with a much
> simpler API for navigating through the mailbox hierarchy and working
> with messages. Will upload it to the repository when it's ready.

Cool!  Looking forward to it.  I'd still suggest making it a subclass of
mailbox.Mailbox, btw.  PEP 20: "There should be one -- and preferably
only one -- obvious way to do it."

Bill