> What I still don't understand:  the new lock is an internal
> implementation detail.  How would it gain a weakref with a callback?
>  Users aren't going to mess with this lock, and if you want to stop
> Python maintainers from giving it a weakref with a callback, simply
> say they shouldn't do that (in the code comments) - you could even
> add code verifying it doesn't have any weakrefs outstanding
> (although that would likely be a waste of time and code:  no
> maintainer is going to _want_ to make a weakref to it, let alone a
> weakref with a callback).

Well... perhaps I'm being too perfectionist, but I don't want Python
to be crashable merely by manipulating a Thread object's private
attributes.
If I add some check code, it will quickly become more complicated than
the current weakref version, which works by design :-)

> My concern is the bulk and obscurity of this code, all to plug such a
> minor hole.  I call it "minor" because it's been reported once in
> the history of the project, and Tamas wormed around it with a
> 1-liner (added a sleep).

Yeah, the overall concern is a bit obscure, but still: right now, if
you use threads inside a subinterpreter, your code can work or crash
depending on subtle timing conditions (where "crash" doesn't even mean
"raise an exception" but "abort the whole process"). So I think it's
worth trying to fix, even though the complication can look a bit
disproportionate.