More RFC 2231 improvements for the email 4.0 package. As Mark Sapiro rightly
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.
diff --git a/Doc/lib/email.tex b/Doc/lib/email.tex
index 6853325..ea12705 100644
--- a/Doc/lib/email.tex
+++ b/Doc/lib/email.tex
@@ -105,7 +105,7 @@
\lineiii{4.0}{Python 2.5}{Python 2.3 to 2.5}
\end{tableiii}
-Here are the major differences between \module{email} verson 4 and version 3:
+Here are the major differences between \module{email} version 4 and version 3:
\begin{itemize}
\item All modules have been renamed according to \pep{8} standards. For
@@ -126,6 +126,15 @@
\item Methods that were deprecated in version 3 have been removed. These
include \method{Generator.__call__()}, \method{Message.get_type()},
\method{Message.get_main_type()}, \method{Message.get_subtype()}.
+
+\item Fixes have been added for \rfc{2231} support which can change some of
+ the return types for \function{Message.get_param()} and friends. Under
+ some circumstances, values which used to return a 3-tuple now return
+ simple strings (specifically, if all extended parameter segments were
+ unencoded, there is no language and charset designation expected, so the
+ return type is now a simple string). Also, \%-decoding used to be done
+ for both encoded and unencoded segments; this decoding is now done only
+ for encoded segments.
\end{itemize}
Here are the major differences between \module{email} version 3 and version 2: