Yes, I have basically made tkinter's Tcl lock into an Rlock.  With respect to Python3's Rlock implementation, though, are you talking about what I see in Modules/_threadmodule.c?  Even if it would be acceptable to make the tkinter module depend on the thread module (not clear), I don't think I can easily use that because it looks like all the relevant functions are static, in typical extension module fashion.  In other words, it provides only a Python API, not a C API.  Moreover, the current implementation can easily be backported to Python 2, but that would not be true of an implementation based on the thread module's Rlock.  If you would nevertheless prefer that the thread module's Rlock be used then I would appreciate technical suggestions for how to overcome the lack of a C API.

I am content to comply with the PSF copyright marking policy.  Is it documented somewhere?  My understanding is that my copyright does not depend in any way on marking the work -- at least in the US -- but there are other reasons to prefer to mark.  Anyway, show me the policy or else just confirm that it is to not mark in cases such as this, and I will remove it.

Tkinter threading and re-entrancy issues have been somewhat of a sore spot for a very long time, so I think this change is worth calling out.  Nevertheless, if Raymund disagrees then so be it.

Thanks