The problem of checking too eagerly for recursive calls is the
following: if a RuntimeError is caused by recursion, and if code needs
to normalize it immediately (as in the 2nd test), then
PyErr_NormalizeException() needs a call to the RuntimeError class to
instantiate it, and this hits the recursion limit again...  causing
PyErr_NormalizeException() to never finish.

Moved this particular recursion check to slot_tp_call(), which is not
involved in instantiating built-in exceptions.

Backport candidate.

constructor, meaning it is treated as *args, not as a single argument.  This
means using the 'message' attribute won't work (until Py3K comes around),
and so one must grab from 'arg' to get the error number.

(http://python.org/sf/1295808)

reference API in pysqlite 2.2.1.

Bumbed pysqlite version number to upcoming pysqlite 2.3.1 release.

os.environ (setting envar COLUMNS), which at least caused
test_float_default() to fail if the tests were run more than once.

This repairs the test_optparse -R failures Neal reported on
python-dev.  It also explains some seemingly bizarre test_optparse
failures we saw a couple weeks ago on the buildbots, when
test_optparse failed due to test_file failing to clean up after
itself, and then test_optparse failed in an entirely different
way when regrtest's -w option ran test_optparse a second time.
It's now obvious that make_parser() permanently changing os.environ
was responsible for the second half of that.

Use ctypes.util.find_library to locate the C runtime library
on platforms where is returns useful results.

as reported by Neal on python-dev.

is_term_resized, resize_term and resizeterm. This uses three
separate configure checks (one for each function).

Fix doctest example.
Mention in the tutorial that 'errcheck' is explained in the ref manual.
Use better wording in some places.
Remoce code examples that shouldn't be in the tutorial.
Remove some XXX notices.

is that the wait is failing for some reason.  Use WNOHANG, so we won't
wait until the buildbot kills the test suite.

I haven't been able to reproduce the failure, so I'm not sure if
this will help or not.  Hopefully, this change will cause the test
to fail, rather than hang.  That will be better since we will get
the rest of the test results.  It may also help us debug the real problem.

issues that crop up from time to time, but this change seems to have been
pretty stable (no spurious warnings) for about a week.

Other modules which use threads may require similar use of
threading_setup/threading_cleanup from test_support.