Is multifile fixed or broken in 2.2?

[Stuart D. Gathman]

On Mon, 07 Oct 2002 15:04:14 -0400, Stuart D. Gathman wrote:


> 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.

-- 
Stuart D. Gathman <stuart at 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.