Staging
v0.5.1
v0.5.1
https://github.com/python/cpython
Revision f5853f7592fac39e7f6d0bccc0884b666b9edd99 authored by Barry Warsaw on 08 February 2006, 13:33:20 UTC, committed by Barry Warsaw on 08 February 2006, 13:33:20 UTC
(.set_payload() gives bad .get_payload() results). Specific changes include: Simplfy the default CODEC_MAP in Charset.py to not include the Japanese and Korean codecs. The names of the codecs are different depending on whether you're using Python 2.4 and 2.5, which include the codecs by default, or earlier Python's which provide the codecs under different names as a third party library. Now, we attempt to discover which (if either) is available and populate the CODEC_MAP as appropriate. Message.set_charset(): When the message does not already have a Content-Transfer-Encoding header, instead of just adding the header, we also encode the body as defined by the assigned Charset. As before, if the body_encoding is callable, we just call that. If not, then we add a call to body_encode() before setting the header. This way, we guarantee that a message's text payload is always encoded properly. Remove the payload encoding code from Generator._handle_text(). With the above patch, this would cause the body to be doubly encoded. Doing this in the Message class is better than only doing it in the Generator. Added some new tests to ensure everything works correctly. Also changed the way the test_email_codecs.py tests get added (using the same lookup code that the CODEC_MAP adjustments use). This resolves both issues for email 2.5/Python 2.3. I will patch forward to email 3.0 for both Python 2.4 and 2.5.
1 parent 784fccf
Tip revision: f5853f7592fac39e7f6d0bccc0884b666b9edd99 authored by Barry Warsaw on 08 February 2006, 13:33:20 UTC
Patches to address SF bugs 1409538 (Japanese codecs in CODEC_MAP) and 1409455
Patches to address SF bugs 1409538 (Japanese codecs in CODEC_MAP) and 1409455
Tip revision: f5853f7
aclocal.m4
# Code swiped wholesale from the GCC project, see
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12100
# This file can go away once autoconf 2.58 is out and being used -
# it's reported that this is fixed in the autoconf cvs already.
# AC_LANG_FUNC_LINK_TRY(C)(FUNCTION)
# ----------------------------------
# Don't include <ctype.h> because on OSF/1 3.0 it includes
# <sys/types.h> which includes <sys/select.h> which contains a
# prototype for select. Similarly for bzero.
#
# A similar problem afflicts HP/UX, but it also hits <sys/time.h>
#
# This test used to merely assign f=$1 in main(), but that was
# optimized away by HP unbundled cc A.05.36 for ia64 under +O3,
# presumably on the basis that there's no need to do that store if the
# program is about to exit. Conversely, the AIX linker optimizes an
# unused external declaration that initializes f=$1. So this test
# program has both an external initialization of f, and a use of f in
# main that affects the exit status.
#
m4_define([AC_LANG_FUNC_LINK_TRY(C)],
[AC_LANG_PROGRAM(
[/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char $1 (); below.
Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
<limits.h> exists even on freestanding compilers. Under hpux,
including <limits.h> includes <sys/time.h> and causes problems
checking for functions defined therein. */
#if defined (__STDC__) && !defined (_HPUX_SOURCE)
# include <limits.h>
#else
# include <assert.h>
#endif
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
{
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char $1 ();
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_$1) || defined (__stub___$1)
choke me
#else
char (*f) () = $1;
#endif
#ifdef __cplusplus
}
#endif
], [return f != $1;])])
Computing file changes ...
