in the byte code and co_consts even if they were not used, ie
immediately popped off the stack.

on each iteration.  I'm not positive this is the best way to handle
this.  I'm also not sure that there aren't other cases where
the lnotab is generated incorrectly.  It would be great if people
that use pdb or tracing could test heavily.

Also:
 * Remove dead/duplicated code that wasn't used/necessary
   because we already handled the docstring prior to entering the loop.
 * add some debugging code into the compiler (#if 0'd out).

str(exception) raised an exception.

for stream decoder, but final=True for the decode function.

Document that using the wrong calling convention can also raise
'ValueError: Procedure called with the wrong number of arguments'.

a socket operation on a socket with a timeout, the exception will be
caught correctly.  Previously, the exception was not caught.

writing the crc to file on the "PPC64 Debian trunk" buildbot
when running test_tarfile.

This is again a case where the native zlib crc is an unsigned
32-bit int, but the Python wrapper implicitly casts it to
signed C long, so that "the sign bit looks different" on
different platforms.

Reported by Klocwork #36

buildbot (& possibly other 64-bit boxes) during test_gzip.

The native zlib crc32 function returns an unsigned 32-bit integer,
which the Python wrapper implicitly casts to C long.  Therefore the
same crc can "look negative" on a 32-bit box but "look positive" on
a 64-bit box.  This patch papers over that platform difference when
writing the crc to file.

It may be better to change the Python wrapper, either to make
the result "look positive" on all platforms (which means it may
have to return a Python long at times on a 32-bit box), or to
keep the sign the same across boxes.  But that would be a visible
change in what users see, while the current hack changes no
visible behavior (well, apart from stopping the struct deprecation
warning).

Note that the module-level write32() function is no longer used.

directory. It also fixes a bug where PythonLauncher failed to launch scripts
when the scriptname (or the path to the script) contains quotes.

on MacOS X actually works correctly in all cases.

KeyboardInterrupt.

Patch by Douglas Greiman.

The test_run_abort() testcase produces a core file on Unix systems,
even though the test is successful. This can be confusing or alarming
to someone who runs 'make test' and then finds that the Python
interpreter apparently crashed.

in the cast() function.

[Bug #1514540] Instead of putting the standard types in a section, put them in a chapter of their own.  This means string methods will now show up in the ToC.  (Should the types come before or after the functions+exceptions+constants chapter?  I've put them after, for now.)

Is the explanation of the 'stacklevel' parameter clear?  Please feel free
to edit it.

I don't have LaTeX installed on this machine, so haven't verified that the
markup is correct.  Will check tonight, or maybe the automatic doc build will
tell me.