summaryrefslogtreecommitdiffstats
path: root/Lib/email
Commit message (Collapse)AuthorAgeFilesLines
* parse(), _parseheaders(), _parsebody(): A fix for SF bug #633527,Barry Warsaw2002-11-051-9/+22
| | | | | | | | | | | | | | | | | | where in lax parsing, the first non-header line after a header block (e.g. the first line not containing a colon, and not a continuation), can be treated as the first body line, even without the RFC mandated blank line separator. rfc822 had this behavior, and I vaguely remember problems with this, but can't remember details. In any event, all the tests still pass, so I guess we'll find out. ;/ This patch works by returning the non-header, non-continuation line from _parseheader() and using that as the first header line prepended to fp.read() if given. It's usually None. We use this approach instead of trying to seek/tell the file-like object.
* test_no_separating_blank_line(): A test for SF bug #633527, noBarry Warsaw2002-11-051-16/+36
| | | | | | separating blank line between a header block and body text. Tests both lax and strict parsing.
* 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_text_plain_in_a_multipart_digest(): A test of the fix for SF bugBarry Warsaw2002-11-051-0/+4
| | | | | #631350, where a subobject in a multipart/digest isn't a message/rfc822.
* _parsebody(): A fix for SF bug #631350, where a subobject in aBarry Warsaw2002-11-051-2/+6
| | | | | | | | | | multipart/digest isn't a message/rfc822. This is legal, but counter to recommended practice in RFC 2046, $5.1.5. The fix is to look at the content type after setting the default content type. If the maintype is then message or multipart, attach the parsed subobject, otherwise use set_payload() to set the data of the other object.
* 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.
* Bump __version__ (yes, to 2.5 "minus")Barry Warsaw2002-11-051-1/+1
|
* Jason Mastaler's patch to break the dependence on rfc822.py for theBarry Warsaw2002-11-052-5/+446
| | | | address parsing routines. Closes SF patch #613434.
* test_body_encoding(): a new test for Charset.body_encode(), especiallyBarry Warsaw2002-10-211-0/+14
| | | | one that tests the obscure bug reported in SF # 625509.
* test_body_encoding(): a new testBarry Warsaw2002-10-211-0/+23
|
* body_encode(): Fixed typo reported by Chris Lawrence, closing SF bugBarry Warsaw2002-10-211-1/+1
| | | | | | #625509. This isn't a huge problem because at the moment there are no built-in charsets for which header_encoding is QP but body_encoding is not.
* append(): Fixing the test for convertability after consultation withBarry Warsaw2002-10-141-14/+28
| | | | | | | Ben. If s is a byte string, make sure it can be converted to unicode with the input codec, and from unicode with the output codec, or raise a UnicodeError exception early. Skip this test (and the unicode->byte string conversion) when the charset is our faux 8bit raw charset.
* Two new tests for splitting (or not splitting) 8-bit header data.Barry Warsaw2002-10-141-0/+21
|
* Bump the __version__Barry Warsaw2002-10-141-1/+1
|
* __init__(): Fix an invariant, that the charset item in a chunk tupleBarry Warsaw2002-10-141-2/+11
| | | | | | | | | | must be a Charset instance, not a string. The bug here was that self._charset wasn't being converted to a Charset instance so later .append() calls which used the default charset would break. _split(): If the charset of the chunk is '8bit', return the chunk unchanged. We can't safely split it, so this is the avenue of least harm.
* _split_header(): If we have a header which is a byte string containingBarry Warsaw2002-10-141-1/+17
| | | | | | | | | 8-bit data, we cannot split it safely, so return the original string unchanged. _is8bitstring(): Helper function which returns True when we have a byte string that contains non-ascii characters (i.e. mysterious 8-bit data).
* CHARSETS: Add faux '8bit' encoding for representing raw 8-bit data forBarry Warsaw2002-10-141-0/+2
| | | | which we know nothing else.
* _encode_chunks(), encode(): Don't modify self._chunks. As Ben says:Barry Warsaw2002-10-131-23/+22
| | | | | | | | | Also, it fixes a really egregious error in Header.encode() (really in Header._encode_chunks()) that could cause a header to grow and grow each time encode() was called if output_codec was different from input_codec. Also, fix a typo.
* Update the urls and other information about the add-on Japanese,Barry Warsaw2002-10-131-13/+8
| | | | Korean, and Chinese codecs.
* Bump version number to 2.4.2 to pick up the latest minor bug fixes.Barry Warsaw2002-10-101-1/+1
|
* New tests to verify that charsets are case insensitive, and that byBarry Warsaw2002-10-101-0/+34
| | | | default get_body_encoding() cannot be SHORTEST.
* get_content_charset(): RFC 2046 $4.1.2 says charsets are not caseBarry Warsaw2002-10-101-4/+6
| | | | sensitive. Coerce the argument to lower case.
* __init__(): RFC 2046 $4.1.2 says charsets are not case sensitive.Barry Warsaw2002-10-101-1/+3
| | | | | Coerce the argument to lower case. Also, since body encodings can't be SHORTEST, default the CHARSETS failobj's second item to BASE64.
* openfile(): Go back to opening the files in text mode. This undoesBarry Warsaw2002-10-072-2/+2
| | | | | | the change in revision 1.11 (test_email.py) in response to SF bug #609988. We now think that was the wrong fix and that WinZip was the real culprit there.
* _parsebody(): Use get_content_type() instead of the deprecatedBarry Warsaw2002-10-071-5/+6
| | | | | | | get_type(). Also, one of the regular expressions is constant so might as well make it a module global. And, when splitting up digests, handle lineseps that are longer than 1 character in length (e.g. \r\n).
* Bump the version to 2.4.1 (not 2.5 as previously mentioned) to sync itBarry Warsaw2002-10-071-1/+1
| | | | with the standalone mimelib package.
* test__all__(): Fix the import list.Barry Warsaw2002-10-011-4/+4
|
* Docstring consistency with the updated .tex files.Barry Warsaw2002-10-011-3/+3
|
* _structure(): Swap fp and level arguments.Barry Warsaw2002-10-011-2/+2
|
* Docstring consistency with the updated .tex files.Barry Warsaw2002-10-011-6/+15
|
* Docstring consistency with the updated .tex files.Barry Warsaw2002-10-012-17/+17
|
* Docstring consistency with the updated .tex files.Barry Warsaw2002-09-301-3/+4
|
* Docstring consistency with the updated .tex files.Barry Warsaw2002-09-301-3/+3
|
* Docstring consistency with the updated .tex files.Barry Warsaw2002-09-301-3/+3
|
* Docstring consistency with the updated .tex files.Barry Warsaw2002-09-301-3/+3
|
* __all__: UpdatedBarry Warsaw2002-09-301-20/+22
|
* Docstring consistency with the updated .tex files.Barry Warsaw2002-09-301-0/+14
|
* __contains__(): Change the second argument to `name' for consistency.Barry Warsaw2002-09-301-58/+69
| | | | | | I seriously doubt this will break any deployed code. Docstring consistency with the updated .tex files.
* With help from Martin v. Loewis, clarification is added for theBarry Warsaw2002-09-301-29/+61
| | | | | | | | | | | | | | | | | | | | semantics of header chunks using byte and Unicode strings. Specifically, append(): When the given string is a byte string, charset (whether specified explicitly in the argument list or implicitly via the constructor default) is the encoding of the byte string, and a UnicodeError will be raised if the string cannot be decoded with that charset. If s is a Unicode string, then charset is a hint specifying the character set of the characters in the string. In this case, when producing an RFC 2822 compliant header using RFC 2047 rules, the Unicode string will be encoded using the following charsets in order: us-ascii, the charset hint, utf-8. __init__(): Use the global USASCII Charset instance when the charset argument is None. Also, clarification in the docstring. Also, use True/False where appropriate.
* The ansi_x3.4_1968 encoding is an alias for ascii, but isn't known inBarry Warsaw2002-09-302-12/+9
| | | | | | | | Python 2.1.3. However it's required by the email tests suite, so poke it into the encodings aliases if it's missing. The is apparently the approved API for doing so. Now we can remove the hexversion shortcircuits in the test suite.
* Make the tests pass under Python 2.1 but only by cheating. Python 2.1Barry Warsaw2002-09-281-0/+12
| | | | | doesn't know about the ansi-x3.4-1968 charset so skip two tests that rely on that (msg_32.txt and msg_33.txt).
* Add a test for SHORTEST encoding of utf-8 headers, and also updateBarry Warsaw2002-09-281-9/+16
| | | | some of the test values which change because of this.
* Use True/False everywhere, and other code cleanups.Barry Warsaw2002-09-282-18/+30
|
* Code cleanup and add docstrings.Barry Warsaw2002-09-281-2/+17
|
* Use True/False everywhere, and other code cleanups.Barry Warsaw2002-09-281-7/+11
|
* Use True/False everywhere.Barry Warsaw2002-09-281-5/+12
|
* is_multipart(): Use isinstance() instead of type equality.Barry Warsaw2002-09-281-1/+1
|
* Docstring and code cleanups, e.g. use True/False everywhere.Barry Warsaw2002-09-281-58/+62
|
* __init__(): Minor code cleanup.Barry Warsaw2002-09-281-1/+1
|
* Add a pychecker suppression.Barry Warsaw2002-09-281-0/+4
|
generated by cgit v0.12 at 2025-01-31 15:57:06 (GMT)