have to wade through all the 'build' output when testing installation.

Caught up with renaming in 'install_misc' base class.
Changed 'run()' to chmod installed scripts under Unix.

  - renamed '_copydata()' to 'copy_files()'
  - changed it to record complete output filenames
  - dropped '_outputdata()' in favour of much simpler 'get_outputs()'

family, including the new 'install_scripts' and 'install_data' commands.

adds the 'install_data' and 'install_scripts' commands; these two
are trivial thanks to the 'install_misc' base class in cmd.py.
(Minor tweaks and commentary by me; the code is untested so far.)

Tweaked error-generating code.

  - added 'find_config_files()' and 'parse_config_files()' methods
  - added 'command_options' attribute
Comment/docstring updates.

added a global '_environ_checked' so we know if it's already been
called.

Also added creation of 'implib_dir', a temporary directory specific to
  MSVC++ -- but I checked in two ways of fixing it (Lyle's and mine),
  because I'm not sure which is right.

that before) in the previous patch has one problem; rint() is not in
the C math library on all platforms (e.g. not for VC++).  Make it
conditional on HAVE_RINT.

Calling Sleep(0) for a spinlock can cause a priority inversion, adding
comments to explain what's going on.

extern "C" for C++.

        Explain that the name of the initialization function must be
        init<module>().  Omission noted by Daniel Kozan
        <crum@dev-group.com>.

the notice yet).

like the short, ambiguous name.

        Instead of using Netscape through os.system(), use the new
        browser.open() function to load the documentation on the
        default browser.  On Windows, this will use the installed
        documentation if it exists, instead of hitting python.org.

Web browsers.

GUSI 2.0.5 has a non-functional getsockname() if you use Open Transport. For now the workaround is to only enable MacTCP sockets.

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.