I rewrote the test code in threading.py
to exercise it a bit more completely,
and found the following exception.
I think it arises because of a race
condition.   Ownership probably changes
in the interval between the two
parts of the "and" on line 90.


Exception in thread gtp0:
Traceback (most recent call last):
  File "/tmp/threading.py", line 460, in __bootstrap
    self.run()
  File "/tmp/threading.py", line 440, in run
    self.__target(*self.__args, **self.__kwargs)
  File "g_threading.py", line 107, in __a_thread
    self.sclock.wait()
  File "/tmp/threading.py", line 216, in wait
    self._note("%s.wait(): got it", self)
  File "/tmp/threading.py", line 46, in _note
    format = format % args
  File "/tmp/threading.py", line 189, in __repr__
    return "<Condition(%s, %d)>" % (self.__lock, len(self.__waiters))
  File "/tmp/threading.py", line 90, in __repr__
    self.__owner and self.__owner.getName(),
AttributeError: 'NoneType' object has no attribute 'getName'

This was python 2.5.1, running on this:
$ uname -a
Linux chives 2.6.11.4-21.15-smp #1 SMP Tue Nov 28 13:39:58 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
$ 


I attach a patch to threading.py that exhibits
the bug (i.e. better testing code).

The race condition should be fixed in rev 56633 in Subversion. I didn't check in the test code changes, because they don't appear to actually exercise the affected code path (there is no code to call repr() on the RLock).

__repr__ gets called in obscure and complicated ways
when _VERBOSE gets set.  This happens when you run
threading.py as a script, rather than loading it as a
module.  Trust me:   __repr__ got called.
I can tell because the exception says so.

The important feature of the test code is that it
calls sys.setcheckinterval() with various arguments.
All good threading tests should do so: it allows
the test to explore many more potential race conditions.

Python, by default, checks for a thread switch every 10 or
100 instructions.   Consequently, it could go entirely through
a critical section between thread switches.    Instead,
if you call sys.setcheckinterval() with various arguments
like 1, 2, 3, 5, ... 100, ...  you arrange for the thread
switches to happen in all different places.   This will reveal
many more bugs, if you have them.