From draghuram at gmail.com  Mon Jun 11 20:54:38 2007
From: draghuram at gmail.com (Raghuram Devarakonda)
Date: Mon, 11 Jun 2007 14:54:38 -0400
Subject: [Email-SIG] deprecation of multifile
Message-ID: <2c51ecee0706111154h21646a67s368288643e18696d@mail.gmail.com>

Hi,

I am trying to remove the usage of "multifile" from stdlib as it is
deprecated. Please see the following python-dev thread in this regard:

http://mail.python.org/pipermail/python-dev/2007-May/073540.html

The only place it is used is in mhlib.py as follows:

--------
       mf = multifile.MultiFile(self.fp)
       mf.push(bdry)
       parts = []
       while mf.next():
           n = "%s.%r" % (self.number, 1 + len(parts))
           part = SubMessage(self.folder, n, mf)
           parts.append(part)
       mf.pop()
---------

As can be seen, multifile is being used purely as file splitting
entity without having to do anything with email. It appears that
replacing this usage with something from email package is not
straightforward. One approach as suggested by Barry is (I hope Barry
doesn't mind my verbatim copying of his suggestion):

"If the message in self.fp has an existing Content-Type header with bdry as the
boundary, then you can just parse the message and use Message.walk()
to iterate over the subparts.  Basically, you'd wrap the str() of
each subpart in a cStringIO to get file-like semantics."

I think that it is better to not deprecate multifile rather than make
non-trivial changes. We can still explicitly mention in the multifile
doc  that "for email related usage, email package should be used". I
am posting this to see if someone has a better idea of replacing
multifile usage from mhlib.py or if some one has any objections to not
deprecating multifile.

Thanks,
Raghu