svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r77542 | r.david.murray | 2010-01-16 13:30:03 -0500 (Sat, 16 Jan 2010) | 18 lines
Merged revisions 77517,77525 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
Merge adds an additional test for as_string with a maxheaderlen specified.
........
r77517 | r.david.murray | 2010-01-16 00:15:17 -0500 (Sat, 16 Jan 2010) | 6 lines
Issue #1670765: Prevent email.generator.Generator from re-wrapping
headers in multipart/signed MIME parts, which fixes one of the sources of
invalid modifications to such parts by Generator. Patch and tests by
Martin von Gagern.
........
r77525 | r.david.murray | 2010-01-16 11:08:32 -0500 (Sat, 16 Jan 2010) | 2 lines
Fix issue number in comment.
........
................
svn+ssh://pythondev@svn.python.org/python/branches/py3k
................
r75307 | r.david.murray | 2009-10-09 20:13:32 -0400 (Fri, 09 Oct 2009) | 12 lines
Merged revisions 75301 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r75301 | r.david.murray | 2009-10-09 17:50:54 -0400 (Fri, 09 Oct 2009) | 5 lines
Issue #7082: When falling back to the MIME 'name' parameter, the
correct place to look for it is the Content-Type header.
Patch by Darren Worrall.
........
................
making it unicode with the default encoding. I'm not sure if this is
a problem in and of itself. However, the test seems to be testing
something different, so at least get that working. Need to revisit
the unicode problem.
SF bug #1403349 solution for email 3.0; some MUAs use the 'file' parameter
name in the Content-Distribution header, so Message.get_filename() should fall
back to using that. Will port to the Python 2.5 trunk.
Also, bump the email package version to 3.0.1 for eventual release. Of
course, add a test case too.
XXX Need to update the documentation.
caused by a self._input.readline() call that wasn't checking for the
NeedsMoreData marker.
msg_43.txt contains a message that illustrates the problem, when
email.message_from_*() is called. That interface uses the Parser API, which
splits reads into 8192 byte chunks. It so happens that for the test message,
the 8192 chunk falls inside a message/delivery-status, which is where in the
FeedParser the readline() call was that didn't check for NeedsMoreData.
I also added an assert to unreadline() so it'll be more evident if an attempt
to push back NeedsMoreData ever happens again.
Bump the email package version number.
Briefly (from the NEWS file):
- Updates for the email package:
+ All deprecated APIs that in email 2.x issued warnings have been removed:
_encoder argument to the MIMEText constructor, Message.add_payload(),
Utils.dump_address_pair(), Utils.decode(), Utils.encode()
+ New deprecations: Generator.__call__(), Message.get_type(),
Message.get_main_type(), Message.get_subtype(), the 'strict' argument to
the Parser constructor. These will be removed in email 3.1.
+ Support for Python earlier than 2.3 has been removed (see PEP 291).
+ All defect classes have been renamed to end in 'Defect'.
+ Some FeedParser fixes; also a MultipartInvariantViolationDefect will be
added to messages that claim to be multipart but really aren't.
+ Updates to documentation.
binary distros (read RPMs) don't include the test module in their
standard Python package. This eliminates an external dependency and
closes SF bug # 650441.
project, and with assistance from Oleg Broytmann. Specifically,
added some new tests to make sure we handle RFC 2231 encoded
parameters correctly. Two new data files were added which contain RFC
2231 encoded parameters.
(i.e. email.test), so move the guts of them here from Lib/test. The
latter directory will retain stubs to run the email.test tests using
Python's standard regression test.
test_email_torture.py is a torture tester which will not run under
Python's test suite because I don't want to commit megs of data to
that project (it will fail cleanly there). When run under the mimelib
project it'll stress test the package with megs of message samples
collected from various locations in the wild.
email/test/data is a copy of Lib/test/data. The fate of the latter is
still undecided.