summaryrefslogtreecommitdiffstats
path: root/Lib/email/utils.py
Commit message (Collapse)AuthorAgeFilesLines
* Patch #2167 from calvin: Remove unused importsChristian Heimes2008-02-231-1/+0
|
* decode_rfc2231(): As Christian Robottom Reis points out, it makes no sense toBarry Warsaw2006-10-041-4/+0
| | | | test for parts > 3 when we use .split(..., 2).
* More RFC 2231 improvements for the email 4.0 package. As Mark Sapiro rightlyBarry Warsaw2006-07-211-19/+35
| | | | | | | | | | | | | | | | | | | | | | | | points out there are really two types of continued headers defined in this RFC (i.e. "encoded" parameters with the form "name*0*=" and unencoded parameters with the form "name*0="), but we were were handling them both the same way and that isn't correct. This patch should be much more RFC compliant in that only encoded params are %-decoded and the charset/language information is only extract if there are any encoded params in the segments. If there are no encoded params then the RFC says that there will be no charset/language parts. Note however that this will change the return value for Message.get_param() in some cases. For example, whereas before if you had all unencoded param continuations you would have still gotten a 3-tuple back from this method (with charset and language == None), you will now get just a string. I don't believe this is a backward incompatible change though because the documentation for this method already indicates that either return value is possible and that you must do an isinstance(val, tuple) check to discriminate between the two. (Yeah that API kind of sucks but we can't change /that/ without breaking code.) Test cases, some documentation updates, and a NEWS item accompany this patch.
* decode_rfc2231(): Be more robust against buggy RFC 2231 encodings.Barry Warsaw2006-07-171-3/+8
| | | | | | | | | | | | | | | | | Specifically, instead of raising a ValueError when there is a single tick in the parameter, simply return that the entire string unquoted, with None for both the charset and the language. Also, if there are more than 2 ticks in the parameter, interpret the first three parts as the standard RFC 2231 parts, then the rest of the parts as the encoded string. Test cases added. Original fewer-than-3-parts fix by Tokio Kikuchi. Resolves SF bug # 1218081. I will back port the fix and tests to Python 2.4 (email 3.0) and Python 2.3 (email 2.5). Also, bump the version number to email 4.0.1, removing the 'alpha' moniker.
* Merge email package 4.0 from the sandbox, including documentation, test cases,Barry Warsaw2006-03-181-0/+306
and NEWS updates.