[Python-bugs-list] [ python-Bugs-514676 ] multifile different in 2.2 from 2.1.1

Tue, 12 Feb 2002 11:22:30 -0800

Bugs item #514676, was opened at 2002-02-07 22:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514676&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Guido van Rossum (gvanrossum)
Summary: multifile different in 2.2 from 2.1.1

Initial Comment:
Reported to python-help. When the test program I'll
attach is run on the test mail I'll attach separately,
it produces this under Python 2.1.1:

TYPE: multipart/mixed
BOUNDARY: =====================_590453667==_
TYPE: multipart/alternative
BOUNDARY: =====================_590453677==_.ALT
TYPE: text/plain
LINES: ['test A\n']
TYPE: text/html
LINES: ['<html>\n', '<b>test B</font></b></html>\n',
'\n']
TYPE: text/plain
LINES: ['Attached Content.\n', 'Attached Content.\n',
'Attached 
Content.\n', 'Attached Content.\n','\n']

But under Python 2.2, it produces:

TYPE: multipart/mixed
BOUNDARY: =====================_590453667==_
TYPE: text/plain
LINES: ['Attached Content.\n', 'Attached Content.\n',
'Attached 
Content.\n', 'Attached Content.\n']

The first output appears to me to be correct.

----------------------------------------------------------------------

>Comment By: Matthew Cowles (mdcowles)
Date: 2002-02-12 11:22

Message:
Logged In: YES 
user_id=198518

It turns out that the problem is more intractable than I thought at first. Here's what seems to happen: the readahead function can consume the separator before the user calls push() with it. Since the readahead function decides whether or not a line matches a separator, the push() comes too late and the line is returned as ordinary data.

Of course Martijn Pieters is right about conformance to RFC 2046 but it's not obvious to me how to strip the last line-end before a separator and also avoid consuming separators that shouldn't be consumed and retain the public interface of the module.

I think that the simplest thing to do would be to resotre the functionality that was in revision 1.18 and tell people who need strict conformance to RFC 2046 that they should use the email module instead since it does strip the last line end before a separator.

The person who posed the original question would be happy to have his files used as part of a test suite.

----------------------------------------------------------------------

Comment By: Matthew Cowles (mdcowles)
Date: 2002-02-10 20:49

Message:
Logged In: YES 
user_id=198518

It seems that SourceForge won't let me delete the patch.
Please ignore it.

----------------------------------------------------------------------

Comment By: Matthew Cowles (mdcowles)
Date: 2002-02-10 20:47

Message:
Logged In: YES 
user_id=198518

Sorry, I think my analysis is right but the patch is flawed and I've deleted it. I'll try to have another look at it tomorrow.

----------------------------------------------------------------------

Comment By: Matthew Cowles (mdcowles)
Date: 2002-02-10 20:20

Message:
Logged In: YES 
user_id=198518

The problem is in _readline(). Since it changes self.level and self.last, they apply to the next line, not the current one. I'll upload a patch that seems to work.

The test program and test mail aren't mine. They belong to the person who reported the bug to python-help. I'm sure that he'd be glad to have them used as part of the test suite but I'll mail him to make absolutely certain.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-08 13:43

Message:
Logged In: YES 
user_id=6380

You're absolutely right -- this is a bug.

Can you suggest a fix?

We also need a test suite!  Your test program is a beginning
for that...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514676&group_id=5470