test_builtin.)

copying to, a wrong location (it copied the DLL under the
Python directory, and gave it name 'PCbuild').

The Windows buildbots other than mine are probably hung
now, waiting for someone to press "OK" on a popup box
informing them that sqlite3.dll couldn't be found.

os.startfile is not present.

This file is used by test_startfile.py.

that they work with all encodings. For UnicodeReader the real
input stream is wrapped in a line iterator that reencodes the
input to UTF-8. For UnicodeWriter the UTF-8 encoded output is
written to a queue for where it is reencoded to the target
encoding and written to the real output stream.

least as big as a long. I believe this to be a safe assumption that is being
made in many parts of CPython, but a check could be added.

len(xrange(sys.maxint)) works now, so fix the testsuite's odd exception for
64-bit platforms too. It also fixes 'zip(xrange(sys.maxint), it)' as a
portable-ish (if expensive) alternative to enumerate(it); since zip() now
calls len(), this was breaking on (real) 64-bit platforms. No additional
test was added for that behaviour.

is 'python'. But 'python' is actually a directory, 'python.exe' is the
executable.

- The buildbot "fetch it" step failed at the end, due to
  using Unix syntax in the final "copy the DLL" step.
  test_sqlite was skipped as a result.

- test_sqlite is no longer an expected skip on Windows.

techniques as in Modules/xxsubtype.c

Re-enable all the tests in test_trace.py except one.  Still not sure that these tests test what they used to test, but they pass.  One failing test seems to be caused by undocumented line number table behavior in Python 2.4.

(see buildbot)