Is multifile fixed or broken in 2.2?
Stuart D. Gathman
python-2.2 on the multipart section. Which one is right?
import multifile
import StringIO
testmsg="""
--------------7EC2082FC4F651D73FCD6FE1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Agent 1
I hope you can read this. Whenever you write label it P.B.S kids.
Eliza doesn't know a thing about P.B.S kids. got to go by
agent one.
--------------7EC2082FC4F651D73FCD6FE1--
"""
fp = StringIO.StringIO(testmsg)
msg = multifile.MultiFile(fp)
msg.push("------------7EC2082FC4F651D73FCD6FE1")
while msg.next():
print msg.read()
--
Stuart D. Gathman <stu...@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
Martin v. Loewis
> In the small test program below, python-2.1 reads one more newline than
> python-2.2 on the multipart section. Which one is right?
That's difficult to say. Python 2.2.2 will restore the 2.1 behaviour,
for compatibility. This may not be strictly in compliance with all
applicable RFCs, but the 2.2 multifile fixes were causing other
problems.
So it has been decided that multifile stays as it is; users wishing to
process MIME properly should use the email package.
Regards,
Martin
Stuart D. Gathman
The email package, like mimelib, seems to suck the entire message into
memory. (Please tell me I'm wrong.) I process a lot of messages, which
can be 30 Megs or more in size. The milter process cannot keep these in
memory to work on them, or it thrashes. There is no problem having
multiple threads working on spool file copies of the messages.
I need to be able to have the Message object refer to a file location.
This is why I had to write my own 'mime' package instead of using mimelib.
While most features are the same, 'mime' has file like objects for raw
leaf message parts, whereas email/mimelib have strings.
What is the rationale for continuing to use strings rather than file-like
objects for raw message parts? I hate reinventing the wheel, but I can't
keep the messages in memory. I can't just extend the standard API as long
as it uses only string as the type of raw message parts.
Could I work around this by creating a string-like object that reads a
seekable file like object?
--
Stuart D. Gathman <stu...@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - Mozart background
song for the Microsoft "Where do you want to go from here?" commercial.
Stuart D. Gathman
> What is the rationale for continuing to use strings rather than
> file-like objects for raw message parts? I hate reinventing the wheel,
> but I can't keep the messages in memory. I can't just extend the
> standard API as long as it uses only string as the type of raw message
> parts.
I see that it seems dumb to throw away data that you had to parse anyway
to find the section boundaries.
May I propose to have email.Message allow either string or a file-like
object for raw payloads? The set_payload() would accept either. The
get_payload, as_string, and as_file would convert as needed (via
fp.getvalue() or StringIO()). A cache_size parameter would determine how
big a payload can be and still be cached as a string internally. Or
perhaps that can be done with an extension of Parser._parsebody(). But
the key thing is that Message needs to handle file-like objects as
alternative internal storage instead of always using strings.