This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dairiki
Recipients
Date 2001-04-04.18:06:38
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
This is a re-implementation of the stock multifile.py

The main changes:

1. Efficiency:

This version supports calling the read() method with an
argument.
(In many cases, I've found that reading a MultiFile
line by line
is just too slow --- remember multipart messages often
contain
large binary attachments.)

This version performs reads on the underlying input
stream in
larger chunks as well, and uses a regular expression
search to
search for separator lines.

2. Buglets fixed

The original version has a buglet regarding its
handling of the
newline which preceeds a separator line.  According to
RFC 2046,
section 5.1.1 the newline preceeding a separator is
part of the
separator, not part of the preceeding content.  The old
version
of multifile.py treats the newline as part of the
content.  Thus,
it introduces a spurious empty line at the end of each
content.

Matching of the separators:  RFC 2046, section 5.1.1
also states,
that if the beginning of a line matches the separator,
it is a
separator.  The old code ignores only trailing white
space when
looking for a separator line.  This code ignores
trailing anything
on the separator line.
History
Date User Action Args
2007-08-23 15:04:37adminlinkissue413766 messages
2007-08-23 15:04:37admincreate