Peter Bierma

> However, as with all simple solutions, this one doesn't seem to be the right one. I'm digging further. Yeah, as I said, this seems to be a problem with...

> The root cause of this error is the absence of subclasses for BaseNode class. Therefore, the STORE_ATTR (->PyObject_SetAttr->tp_setattro->type_update_dict->type_modified_unlocked) can't reset the cache for subclasses. As a result, the Node...

> Where? How? For what? We need a test case in `test_idlelib` that results in DOS/extreme slowness off main. Basically, just do something to prove that this PR fixes it...

I'll probably have to put together a library for asynchronous and fast logging, with a C API detached from the GIL.

Eh, this seems like the wrong approach. I would be more comfortable with either making the mutex recursive, rather than implicitly releasing it for cases like this.

> Maybe we can wait for a solution to the problem. The solution to that problem is to make it a recursive mutex :)

I'll defer to Sam, as he knows *much* more about locking than I do, but I'm -1 on this, because it's generally a bad idea to implicitly release locks.

@zooba I'm curious about the reason to put this in `sys.implementation`. I'm fine with putting it in `sys` (and that's probably the best place to put it), but `implementation` seems...

I made [an issue](https://github.com/python/devguide/issues/1589) for this, I hadn't seen this PR. Feel free to link to it in the title.

Yeah, sorry about that. I'm used to CPython's workflow where we have an issue for every little thing.