> I'm kind of puzzled on that fact that context manager solves it. 

It "solves" the problem because of the happenstance rather than because of language guarantees.

The current implementation of the with-statement in CPython is to generate a SETUP_WITH opcode that calls both __enter__() and PyFrame_BlockSetup() within a single opcode while the GIL is held.  And because RLlock.__enter__() is implemented in C there are no pure python steps before the block frame setup.

If we added a pure Python __enter__ and __exit__ to the Handler class (necessary because a user can override createLock), then pure python steps would occur before the frame block setup and the problem would reappear.

If RLock were implemented in pure python, the problem would also reappear.

If the opcodes were changed so that the call to __enter__() were in a different opcode than setting up the block frame, the problem would reappear.


> I'll submit a PR in a few days

Let's wait to hear from Vinay and Nick before deciding to work on a PR.  Since you are no longer using the package, you no longer have the problem to solve.  The programming practice that gave rise to the problem is inherently fragile. The proposed mitigation only helps one module and doesn't solve the problem in general.  As described above, the proposed mitigation is fragile and implementation specific.  Lastly, it overrides an old decision to not use context managers in the logging module for reasons I no longer remember.