http://c0re.jp/c0de/misc/python-maildir2.patch

This patch which changes python's mailbox.Maildir class
to move processed messages form new/ to cur/. Although not 
expicity stated in http://cr.yp.to/proto/maildir.html 
all applications using Maildirs I'm aware of move messages 
form new/ to cur/ after the first reading of a message.
This patch gives you a way to get the same behaviour in python
by giving a third parameter to __init__. See 
mailbox.Maildir.__init__.__doc__ 
  --drt@un.bewaff.net - http://c0re.jp/

--- Lib-orig/mailbox.py Sat Sep 29 13:03:12 2001
+++ Lib/mailbox.py      Sat Sep 29 13:36:36 2001
@@ -201,11 +201,16 @@
 
 
 class Maildir:
-    # Qmail directory mailbox
+    # qmail/maildrop directory mailbox
+    # see http://cr.yp.to/proto/maildir.html
 
-    def __init__(self, dirname, factory=rfc822.Message):
+    def __init__(self, dirname, factory=rfc822.Message, move=0):
+        '''if you supply the constructor with a third parameter which is
+        not equal 0, this class will mark all messages, you processed with
+        next() as read by moving them from new/ to cur/'''
         self.dirname = dirname
         self.factory = factory
+        self.move = move
 
         # check for new mail
         newdir = os.path.join(self.dirname, 'new')
@@ -225,6 +230,11 @@
         fn = self.boxes[0]
         del self.boxes[0]
         fp = open(fn)
+        if not self.move == 0:
+            # if the message is considered new, mark it as seen
+            (head, tail) = os.path.split(fn)
+            if(head[-3:] == 'new'):
+                os.rename(fn, os.path.join(head[:-3], 'cur', tail + ':2,S'))
         return self.factory(fp)
 
 

Logged In: YES 
user_id=6380

Fred, what do you think? Is this reasonable?

Logged In: YES 
user_id=3066

Having this as an option is more reasonable than making it
do this by default.  It's not at all clear to me that this
is the right thing to do; an application may want to search
the messages without presenting them to the user, so adding
the "seen" flag may not be the right thing.

I think it might be better to return a proxy for the message
returned by the Message factory which adds methods like
get_info() and set_info(s), where s is the new info string.
 Setting the info string would cause the right renaming to
be done.

Regardless of mechanism, this would make this module
something a little different from the strictly read-only
thing it is now.

Barry, what do you think?

Logged In: YES 
user_id=6380

I'm -0 on this. But Fred, he *did* make it an option unless
I misunderstand the "move=0" default arg value. --Guido

Logged In: YES 
user_id=3066

Guido:  I understood that part; my comment was unclear.  I
certainly think the patch as proposed isn't a bad thing, but
its only useful for a specific range of applications. 
Abstracting it differently could make it more widely
applicable without adding a lot to the library.

I'll make a different proposal, that may work a little
better:  we can add a new method for all that mailbox
formats that represent each message as a separate file,
passing in the name of the file.  That method is responsible
for opening the file and returning the message object (with
the default implementation using the registered factory),
which next() then returns.  An application that needs more
than the message object can subclass the mailbox and
override that method to do what's needed.  That should
suffice both for the simple case solved by the patch
provided here and many other possible applications as well.
If that's reasonable, I'll volunteer to make the patch.

Logged In: NO 

fdrakes suggestion seems to me like a very sound suggestion. It is a much cleaner general approach than my hacke-to-solve-my actual problem. 

In my opinion on medium sight Python should support full read and write access to mailboxes, because that are the batteries of mail handling. If there is a good sugestion for an clean interface for that I would be happy to do the Maildir implementation.

--drt@un.bewaff.net

Logged In: YES 
user_id=12800

Assigning back to Fred because he was the last person to put
his finger on his nose (see him volunteer in his comment of
2001-10-01 below :)

Logged In: YES 
user_id=3066

Since this is clearly a new feature for the library and we
didn't get to it in time for the Python 2.2 betas, I'm
marking this postponed and adding it to the Python 2.3 group.

Logged In: YES 
user_id=21627

It appears that the original patch has been rejected, so I'm
closing it now.