Logged In: YES 
user_id=357491

After staring at the code, I am not even sure if the calls for its side-
effect are needed.  If you call currentThread(), it either returns a value 
from _active which is a dict of running Thread instances indexed by 
thread idents, or a new _DummyThread instance that inserts itself into 
_active.  Now the two calls in the _Condition class are purely for this 
possible side-effect.

And yet at no point is anything from _active, through currentThread or 
direct access, even touched by a _Condition method.  The only chance 
this might be an issue is if a _Condition instance uses an RLock instance 
for its locking, which is the default behavior.

But this still makes the side-effect need useless.  RLocks will call 
currentThread on their own and since this is all in the same thread the 
result won't change.  And in this specific case of this bug, the _Condition 
instance is created with a Lock instance since that is what the Thread 
instance uses for constructing the _Condition instance it use, which is just 
thread.allocate_lock() which is obviously not an RLock.

In other words I can't find the point to the side-effect in _Condition.  I 
will try to come up with some testing code that reproduces the error and 
then see if just removing the calls in _Condition remove the error and 
still pass the regression tests.