Use "win32" for sys.platform on Win64 instead of "win32" because:
1. While it may be confusing to the Python scriptor on Win64 that he has to
   check for win*32*, that is something that he will learn the first time. It
   is better than the alternative of the scriptor happily using "win64" and
   then that code not running on Win32 for no good reason.
2. The main question is: is Win64 so much more like Win32 than different from
   it that the common-case general Python programmer should not ever have to
   make the differentiation in his Python code. Or, at least, enough so that
   such differentiation by the Python scriptor is rare enough that some other
   provided mechanism is sufficient (even preferable). Currently the answer
   is yes. Hopefully MS will not change this answer.

Limit the 'b' formatter of PyArg_ParseTuple to valid values of an unsigned
char, i.e. [0,UCHAR_MAX]. It is expected that this is the common usage of 'b'.
An OverflowError is raised if the parsed value is outside this range.

Added a useful link to Markus Kuhn's Unicode and UTF-8
FAQ.

Added another test for string formatting (the one that
produced the core dump now fixed in unicodeobject.c).

Added APIs to allow setting and querying the system's
current string encoding: sys.set_string_encoding()
and sys.get_string_encoding().

Moved some docs to the include file.

Added a NULL check to _PyCodec_Lookup() to make it
core dump safe.

Fixed docs according to the new behaviour (the Unicode
encoding is no longer fixed to UTF-8).

M.-A. Lemburg <mal@lemburg.com>:
Fixed a core dump in PyUnicode_Format().

Added support for user settable default encodings. The
current implementation uses a per-process global which
defines the value of the encoding parameter in case it
is set to NULL (meaning: use the default encoding).

Fixed a bug due to a /* inside /*...*/. GCC doesn't like
this and bombs.

Added PyUnicode_GetDefaultEncoding() and
PyUnicode_GetDefaultEncoding() APIs.

Added documentation and the missing PyCodec_StreamWriter API.

into.  Jim writes:

The core dump was due to a C decrement operation
in a macro invocation in load_pop.  (BAD)

I fixed this by moving the decrement outside
the macro call.

I added a comment to load_pop and load_mark
to document the fact that cPickle separates the
unpickling stack into two separate stacks, one for
objects and one for marks.

I also moved some increments out of some macro
calls (PyTuple_SET_ITEM and PyList_SET_ITEM).
This wasn't necessary, but made me feel better. :)

I tested these changes in *my* cPickle, which
doesn't have the new Unicode stuff.

filename parameter.  Noted by Randall Hopper <aa8vb@yahoo.com>.

The intent is that this diff adds a link to the rfc822 module doc and
an index reference to this module under the rfc822 heading.

Fred, based on a suggestion from Grant Griffin <grant.griffin@honeywell.com>:
Added link to the MIME FAQ, so people can more easily get more
information about the subject of the module.

        reasonably.

readfp() method:  added documentation.

the server after it died doesn't require a wait period.

server_bind() method calls setsockopt(SOL_SOCKET, SO_REUSEADDR, 1).

        Instead of wrapping 'filenames' value in a list if it's a
        string, wrap it if it's a string or unicode string.

option name for clarity.

is required" (we can't say more because we don't know in which context
it is called).

Fix the string methods that implement slice-like semantics with
optional args (count, find, endswith, etc.) to properly handle
indeces outside [INT_MIN, INT_MAX]. Previously the "i" formatter
for PyArg_ParseTuple was used to get the indices. These could overflow.

This patch changes the string methods to use the "O&" formatter with
the slice_index() function from ceval.c which is used to do the same
job for Python code slices (e.g. 'abcabcabc'[0:1000000000L]).

with a dot.  [GvR change: only unstuff when line starts with two dots.]

Fixed the help strings.
Swapped the macfsn and help button numbers.

Internet Config to set creator/type based on the extension. Donated by
Oliver Steele.

called.  catch the resulting AttributeError and exit cleanly.

Fix overflow bug in ldexp(x, exp). The 'exp' argument maps to a C int for the
math library call [double ldexp(double, int)], however the 'd'
PyArg_ParseTuple formatter was used to yield a double, which was subsequently
cast to an int. This could overflow.

[GvR: mysteriously, on Solaris 2.7, ldexp(1, 2147483647) returns Inf
while ldexp(1, 2147483646) raises OverflowError; this seems a bug in
the math library (it also takes a real long time to compute the
Inf outcome).  Does this point to a bug in the CHECK() macro?  It
should have discovered that the result was outside the HUGE_VAL range.]

The following modules are specifically excluded in the Win64 build:
audioop, binascii, imageop, rgbimg. They are advertised as heavily 32-bit
dependent.  [They should probably be fixed!  --GvR]

Changes to PC\config.[hc] for Win64. MSVC defines _WINxx to differentiate the
various windows platforms. Python's MS_WINxx are keyed off of these. Note
that _WIN32 (and hence MS_WIN32 in Python) are defined on Win32 *and* on
Win64. This is for compatibility reasons. The idea is that the common case is
that code specific to Win32 will also work on Win64 rather than being
specific to Win32 (i.e. there is more the same than different in WIn32 and
Win64).

The following modules are specifically excluded in the Win64 build:
audioop, binascii, imageop, rgbimg. They are advertised as heavily 32-bit
dependent.  [They should probably be fixed!  --GvR]

The patch to config.h looks big but it really is not. These are the effective
changes:
- MS_WINxx are keyed off _WINxx
- SIZEOF_VOID_P is set to 8 for Win64
- COMPILER string is changed appropriately for Win64

Fix the string methods that implement slice-like semantics with
optional args (count, find, endswith, etc.) to properly handle
indeces outside [INT_MIN, INT_MAX]. Previously the "i" formatter
for PyArg_ParseTuple was used to get the indices. These could overflow.

This patch changes the string methods to use the "O&" formatter with
the slice_index() function from ceval.c which is used to do the same
job for Python code slices (e.g. 'abcabcabc'[0:1000000000L]). slice_index()
is renamed _PyEval_SliceIndex() and is now exported. As well, the return
values for success/fail were changed to make slice_index directly
usable as required by the "O&" formatter.

[GvR: shouldn't a similar patch be applied to unicodeobject.c?]

Change static slice_index() to extern _PyEval_SliceIndex() (with
different return value interpretation: 0 for failure, 1 for success).