➜
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.
Created on 2002-02-08 06:24 by mdcowles, last changed 2022-04-10 16:04 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| test.py | mdcowles, 2002-02-08 06:25 | |||
| testmf.eml | mdcowles, 2002-02-08 06:26 | test mail | ||
| multifile.patch | mdcowles, 2002-02-11 04:23 | Patch | ||
| Messages (8) | |||
|---|---|---|---|
| msg9187 - (view) | Author: Matthew Cowles (mdcowles) | Date: 2002-02-08 06:24 | |
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. |
|||
| msg9188 - (view) | Author: Guido van Rossum (gvanrossum) *  |
Date: 2002-02-08 21:43 | |
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... |
|||
| msg9189 - (view) | Author: Matthew Cowles (mdcowles) | Date: 2002-02-11 04:20 | |
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. |
|||
| msg9190 - (view) | Author: Matthew Cowles (mdcowles) | Date: 2002-02-11 04:47 | |
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. |
|||
| msg9191 - (view) | Author: Matthew Cowles (mdcowles) | Date: 2002-02-11 04:49 | |
Logged In: YES user_id=198518 It seems that SourceForge won't let me delete the patch. Please ignore it. |
|||
| msg9192 - (view) | Author: Matthew Cowles (mdcowles) | Date: 2002-02-12 19:22 | |
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. |
|||
| msg9193 - (view) | Author: Guido van Rossum (gvanrossum) * |
Date: 2002-03-23 03:39 | |
Logged In: YES user_id=6380 Fine with me to roll back the patch. I think that should be a bugfix candidate, maybe for 2.2.2. |
|||
| msg9194 - (view) | Author: Martin v. Löwis (loewis) * |
Date: 2002-09-22 09:04 | |
Logged In: YES user_id=21627 I have backed-out multifile.py 1.19 and 1.20, and committed this as multifile.py 1.22 and 1.1.2.1. I have added the test case as test_multifile.py 1.1 and 1.1.2.1. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-10 16:04:57 | admin | set | github: 36050 |
| 2002-02-08 06:24:37 | mdcowles | create | |