[Patches] [ python-Patches-466352 ] let mailbox.Maildir tag messages as read
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 09 Nov 2001 08:07:58 -0800
Patches item #466352, was opened at 2001-09-29 04:42
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466352&group_id=5470
Category: Library (Lib)
>Group: Python 2.3
Status: Open
>Resolution: Postponed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: let mailbox.Maildir tag messages as read
Initial Comment:
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)
----------------------------------------------------------------------
>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-11-09 08:07
Message:
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.
----------------------------------------------------------------------
Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-18 15:55
Message:
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 :)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-03 11:18
Message:
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
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-10-01 09:19
Message:
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.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-01 08:48
Message:
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
----------------------------------------------------------------------
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-10-01 08:44
Message:
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?
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-30 11:49
Message:
Logged In: YES
user_id=6380
Fred, what do you think? Is this reasonable?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=466352&group_id=5470