> I'm not competent to review Windows-specific stuff, but 
> some style notes:
> - your indentation is inconsistent with the original file
> (you should use tabs)
> - please don't use any C++-style comments

Thanks- I was only supplying the code for testing purposes, but I will
clean it up anyway... and read the style guide closer of course :)

> This isn't obvious to me. I do care about what threading.Lock does,
> but still fail to see why we can't just slap on a criticial section
> and call it done.

If it were up to me, I'd say move forward with breaking the current
functionality. I guess my statement of "obviously" was that breaking it
outright would cause people to complain. After I got to thinking about
it that way, making GIL locking free from any other API seemed like it
would give more leeway for performance improvement.

If anyone is using the semaphore-like features of threading.Lock, they'd
likely be better off using threading.Semaphore anyway :) There are some
places where the core code would have to change in order to reflect the
differences, but otherwise it would be a significant improvement to the
GIL under high concurrency and not much of a change for a single thread.

On the positive side, a global change means that other core code using
locks will also see a speedup with critical sections as the default
thread lock. So I guess my main point is that somehow, whether separate
from or within the thread lock API, the GIL should be a critical section.