Bug in rfc822

[Steve Holden]

"Emmanuel Jeandel" <ejeandel at ens-lyon.fr> wrote in message
news:9ihnv5$e2v$1 at macareux.ens-lyon.fr...
> If someone is playing with rfc822, i'm interested !
>
> I'm writing a small script that does statistics about mailboxes :
> it writes for each sender (respectively receiver) the number of mail
> he sends to you (resp. receives from you), and the total size of mails,
> size  meaning : i drop all html code, attachments (I use multifile
> to consider only the first part of a message) and
> drop all lines beginning with '>' . If someone
> is interested the program can be located in
> http://www.ens-lyon.fr/~ejeandel/mailstat
> (python 1.5, but I think it is 2.0 compliant)
> syntax: mailstat r namesofthemailboxes for parsing inboxes
>         mailstat w .... for parsing outboxes
> you can also use mailstat r20 to parse only the mail from the last 20 days
> (I know that the parsing of the command line is very weak, but i don't
> want to lose my time doing this in a more pretty way)
>
> Playing with rfc822 is good, but i think mailbox.py has also several
> problems. When you do mailbox.next(), the function return a rfc822.Message
> but i wanted to use my class MyMessage, so i have to rewrite :
>
> class MyUnixMailbox(mailbox.UnixMailbox):
>     def next(self):
>         while 1:
>             self.fp.seek(self.seekp)
>             try:
>             self._search_start()
>     except EOFError:
>           self.seekp = self.fp.tell()
>         return None
>     start = self.fp.tell()
>     self._search_end()
>     self.seekp = stop = self.fp.tell()
>     if start <> stop:
>         break
> return MyMessage(mailbox._Subfile(self.fp, start, stop))
>
> Do you know of any prettier solution ?
>

I've come across the same impedance mismatch myself, and adopted more or
less the same solution. It would clearly be nice to be able to pass the
mailbox's __init__() method an (optional, defaulting to rfc822.Message)
class which that mailbox would then use when it was creating messages. The
class would obviously need to comply with (a subset of) the rfc822.Message
interface.

Maybe this upwardly-compatible solution could be adopted for the rfc2822
library?

regards
 Steve

--
http://www.holdenweb.com/