summaryrefslogtreecommitdiffstats
path: root/Lib/email/test/data
Commit message (Collapse)AuthorAgeFilesLines
* Ported 42076 from the trunk.Barry Warsaw2006-01-171-0/+35
| | | | | | | | | | | 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. 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.
* Fixes for SF #1076485, which I'll apply to the CVS head too. The problem wasBarry Warsaw2004-12-051-0/+217
| | | | | | | | | | | | | | | | 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.
* An example message for SF bug # 1030941.Barry Warsaw2004-10-091-0/+20
|
* Big email 3.0 API changes, with updated unit tests and documentation.Barry Warsaw2004-10-031-0/+8
| | | | | | | | | | | | | | | | | 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.
* forward porting from release23-maintBarry Warsaw2004-05-131-0/+10
|
* Another evil test from Anthony's suite. This one has an inner part with theBarry Warsaw2004-05-131-0/+83
| | | | same boundary as the outer part.
* A boiled down example from Anthony's MIME torture tests. This one has aBarry Warsaw2004-05-131-0/+101
| | | | separating boundary for an outer part inside an inner part.
* A boiled down message/external-body example from Anthony's torture test.Barry Warsaw2004-05-111-0/+40
|
* An example with multiple boundary lines.Barry Warsaw2004-05-111-0/+22
|
* Like msg_12.txt but with some extra vertical whitespace around the innerBarry Warsaw2004-05-091-0/+38
| | | | message's end boundary.
* Adjust tests for no newline appending to MIMEText.__init__()'s _textBarry Warsaw2003-03-111-2/+0
| | | | argument.
* A copy of the audio test file from Lib/test, needed because someBarry Warsaw2002-12-301-0/+0
| | | | | | 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.
* A message with no separating blank line between the headers and theBarry Warsaw2002-11-051-0/+4
| | | | body. A test message for SF bug #633527.
* Test case, distilled from SF bug #631350, where a subobject in aBarry Warsaw2002-11-051-0/+19
| | | | | multipart/digest isn't a message/rfc822. This is legal, but counter to recommended practice in RFC 2046, $5.1.5.
* Fixing some RFC 2231 related issues as reported in the SpambayesBarry Warsaw2002-09-262-0/+43
| | | | | | | 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.
* A sample message with broken MIME boundaries.Barry Warsaw2002-09-101-0/+15
|
* The email package's tests live much better in a subpackageBarry Warsaw2002-07-1931-0/+1182
(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.
generated by cgit v0.12 at 2025-12-27 16:28:44 (GMT)