Trent, I was wondering if you could look at some test failures in MS
Windows builds. I can't debug Windows issues myself :-(. This is a MS
free environment...
In these errors I see lots of bsdbd errors, many of the form:
| DBFileExistsError: (17, 'File exists -- __fop_file_setup: Retry limit
(100) exceeded')
Maybe an old test file isn't being nuked? Others of the form:
| self.assertTrue(time.time() (value: u'C:\\\\Program Files\\\\Microsoft Visual Studio
9.0\\\\VC\\\\LIB;C:\\\\Program Files\\\\Microsoft
SDKs\\\\Windows\\\\v6.0A\\\\lib;c:\\\\program files\\\\microsoft visual
studio .NET 2003\\\\vc7\\\\atlmfc\\\\lib;c:\\\\program files\\\\microsoft
visual studio .NET 2003\\\\vc7\\\\lib;c:\\\\program files\\\\microsoft
visual studio .NET 2003\\\\vc7\\\\PlatformSDK\\\\lib;C:\\\\Program
Files\\\\Microsoft Visual Studio .NET 2003\\\\SDK\\\\v1.1\\\\Lib\\\\')" !=
"AssertionError: Headers (('Content-Type', 'text/plain')) must be of type
list: "
So LIB has a Unicode value - evn though it has no Unicode characters, and
was presumably in the environment Python inherited (but presumably was
initially a string).
I can't reproduce the Unicode errors: 'python test_sys.py' works and I
couldn't run a full test suite (see below). Python allows you to set
unicode objects in os.environ, so its possible part of the test suite is
modifying the environment.
I tried to run a full test, but it hangs in various places before test_sys
(bz2, multiprocessing), and I ended up giving up. This was on for either 32
or 64bits with the current trunk, but sadly I've no idea what could be
happening there :(
So it sounds like just tracking down how a unicode object is getting into
the environment will solve the vast majority of the errors - except for the
bsddb and wsgi ones, which don't look particularly Windows specific...
Hope that helps a bit...
Mark