It would be great if the 'mailbox' library supported a 'remove' or 'delete' operation for the mailbox itself as part of its abstract interface. It does support removing messages, and the sub-classes for Maildir, MH etc. support removing sub-folders (their interface is common but they don't inherit a common interface); but removing the actual parent mailbox itself is not yet supported.

Conceptually the problem with this is that if you use the object to delete the folder, you now have an object with no folder...that is,
an invalid object.  Do we have any other stdlib examples of objects with a 'delete()' method...looks like bdb has a deleteMe on breakpoint objects, but it isn't clear that it tries to deal with what happens if a breakpoint object that has been deleted is accessed again.  There are also some in idlelib/tk, which I haven't looked at.

So, I guess the issue is to work out what the semantics of the object would be if delete has been called, and make sure it actually makes sense to have a delete method.

Hi David, thanks for replying!

On Tue, Jan 21, 2014 at 03:08:04PM +0000, R. David Murray wrote:
> Conceptually the problem with this is that if you use the object to
> delete the folder, you now have an object with no folder...that is, an
> invalid object.

You're absolutely right, and it turns out that this library already has
this problem, because the mailbox.Maildir class has a remove_folder
method, which can delete nested Maildirs. The following python code is
enough to expose this problem:

> import mailbox, os
> 
> # create foo/{cur,new,tmp,.bar{,/{cur,new,tmp}}}
> for d in "foo foo/.bar".split():
>   os.mkdir(d)
>   for d2 in "cur new tmp".split():
>     os.mkdir(os.path.join(d,d2))
> 
> mb1 = mailbox.Maildir("foo")
> mb2 = mb1.get_folder("bar")
> mb1.remove_folder("bar")
> print mb2.items()

Of course, if someone is using this module in any real environment where
folders might come and go due to other processes (e.g. an IMAPd - quite
a realistic prospect if you ask me), any mailbox.* object could become
invalid at any time.

Note that mailbox class has a 'lock/unlock' method, but this is a no-op
for mailbox.Maildir.

> Do we have any other stdlib examples of objects with a 'delete()'
> method...looks like bdb has a deleteMe on breakpoint objects, but it
> isn't clear that it tries to deal with what happens if a breakpoint
> object that has been deleted is accessed again.  There are also some
> in idlelib/tk, which I haven't looked at.

That's a very good question. I don't know, I will have to do some
research. I wonder if it's worth looking outside of the python ecosystem
too.

> So, I guess the issue is to work out what the semantics of the object
> would be if delete has been called, and make sure it actually makes
> sense to have a delete method.

Yes. My gut feeling is the module needs to gracefully handle situations
where objects are not valid anymore, to allow inter-operation with other
processes deleting or creating mailboxes outside of Python's control,
but I suppose the first step is the research.

If the consensus is that delete doesn't make sense, I think we need to
address the existing delete_folder methods.

Thanks for your interest,

Could you give this issue a more descriptive name please?

I think your arguments are good ones.  So, if you want to propose a patch that defines some semantics for delete (and possibly address the maildir folder delete similarly), I will review it.  Also fine if you want to discuss it more before working on a patch.  (Also OK if you *don't* want to work on a patch, although in that case it is a lot less likely to happen :)

Hi,

On Fri, Jan 31, 2014 at 03:03:09PM +0000, R. David Murray wrote:
> I think your arguments are good ones.  So, if you want to propose a
> patch that defines some semantics for delete (and possibly address the
> maildir folder delete similarly), I will review it.  Also fine if you
> want to discuss it more before working on a patch.  (Also OK if you
> *don't* want to work on a patch, although in that case it is a lot
> less likely to happen :)

Thanks - I intend to write a patch (my first for Python proper), it will
take me quite a long time (simply due to lack of free time) but when I
have any interesting WIP to share I'll update this bug.

Thanks again

Hi, sorry for the long silence on this issue. I've had a few things going on. Anyway, I didn't want to forget all about this; I've been working on it in two phases. Phase 1 adds delete methods; Phase 2 handles non-existent mailboxes.

Please find attached my first cut at phase 1. I am working on further tests as well, but they aren't quite ready.

patch adding tests

another test

I find it surprising that deleting a mailbox does not delete subfolders.  What is the rationale for that?

Hi David, whilst writing my patch I've tried to keep an open mind as to users of the methods, but I do have my own purpose in the back of my mind, and that's an archive mail tool which I would like to delete mail folders if, after performing an archive operation, they are empty. However, the archive mail tool has no awareness or interest in sub-folders. The user would be surprised, however, if it deleted them, should they exist.

There's also the issue of lack of locks for Maildirs. If one wanted to avoid recursive deleting, how could one achieve it? consider pseudo code

if len(mbox.list_folders()) <= 0:
  # no sub-folders, safe to delete?
  mbox.delete()

There are no guarantees an external process didn't create a sub folder between the test and the delete operation.

Finally, if one has a delete() operation that doesn't operate on sub-folders, but you want to recursively delete, you can at least assemble such a method. If you have a recursively-deleting method, and you *don't* want to delete sub-folders, you're stuck.

Having said all that please let me know what you're thinking; I'll happily try to cook up a patch to add both recursive and non-recursive delete methods.

Well, if you can delete subfolders, then you aren't deleting the main folder, either (unless it is empty?).  So isn't this really a 'delete_messages' method?  In which case, how does it differ from the 'clear' method?  Only in that it deletes the folder if it is empty?  That doesn't sound like a good API to me.

I find myself really confused as to what your goal is here.

Given that there's been no clarification of the problem being solved in several years, I'm going to reject this.  If someone wants to sort it out and improve the patch accordingly we can reopen.