The mailbox module uses the rfc822 module as its
default factory for creating message objects. The
rfc822 documentation claims that its use is deprecated.
The mailbox module should probably use the new email
module as its default factory.

Of course this has backward compatibility issues, in
which case it should at least be mentioned in the
mailbox documentation that it uses the deprecated
rfc822 module, and provide an example of how to use the
email module instead.

Logged In: YES 
user_id=12800

I've added some sample code to the mailbox documentation
that explain how to use the email package with the mailbox
module.  We can't change the default for backward
compatibility reasons, as you point out.

Logged In: YES 
user_id=469548

So, with the plans to seriously start working deprecating
rfc822, should we use the email module as the default
factory now?

Logged In: YES 
user_id=12800

It's a good question.  I'd like to say yes so that we can
start adding deprecation warnings to rfc822 for Python 2.5.

Logged In: YES 
user_id=29957

Given the amount of code out there using rfc822, should we
instead PDW it? In any case, I'm -0 on putting a
DeprecationWarning on it unless we've removed all use of it
from the stdlib. 

The reworking of mailbox.py introduced in Python 2.5 adds new mailbox classes that do use email.Message.  
Arguably we could begin deprecating the old classes (or just remove them all for Python 3000?).

I dunno if this is helpful, but in the 2.5 module, it parses mailboxes
into rfc822 messages, but then expects them to be email.Message messages
when unparsing them back to a mailbox. mbox2.add(mbox1.popitem()[1])
fails with rfc822 as the default factory. Since the "factory" is the
only thing still using rfc822, it's easy to remove the use of rfc822
from this module entirely, which also eliminates the parsing/unparsing
disconnect.

synx's patch wasn't applying cleanly and broke 2 maildir tests. I'm 
posting one with updated tests and documentation. Still need to get rid of 
rfc822 in test_mailbox, though.

Question: mailbox.py has one section marked as "classes from the original 
module (for backward compatibility)". Shouldn't these be removed in py3k?

I think removing those old classes in 3.0 would be very sensible.

I created issue 2814 with a patch to remove those old classes.

I removed the old classes in 3k. There remains one usage of rfc822, as
the default "factory" of Maildir. It's replaced by None in the patch
here; is that safe to do?

> rfc822 is replaced by None in the patch here; is that safe to do?

Yes. That's what mailbox documentation says:

Parameter factory is a callable object that accepts a file-like message 
representation [...] and returns a custom representation. If factory is 
None, MaildirMessage is used as the default message representation.

Removed the last rfc822 reference from 3k's mailbox.py in r63091.

Georg, any special reason for not removing rfc822 references from 
test_mailbox? That section of the patch was not merged.

Okay, removed that too in r63096.