> This is exactly the motivation for context managers, no? I attached no_gc.py, which works when nested and should additionally be thread-safe.

My solution was roughly the same (also a context manager, but a bit simplified because I didn't need threading support so I didn't bother with locking).

> There is also gc.isenabled(), so couldn't you check that before disabling and remember whether you needed to disable or not?

Yes, but it must be protected like Dennis suggested, otherwise it can't be used in a race-free way, for example this snippet is susceptible to a thread switch between the `isenabled()` and `disable()` calls (so another thread could meanwhile disable GC, and we retain a stale `was_enabled` result)

     was_enabled = gc.isenabled()
     gc.disable()
     ...
     if was_enabled:
         gc.enable()

My points in this issue are:

1. I think that such a safer API should be available in the standard library (I don't want to find myself repeating this across different projects). I think that wherever you find yourself using `gc.disable()` you should actually be using a safer API (that takes into account multithreading & previous invocations of `gc.disable()`)
2. A tiny change in `gc.enable()` (as I suggested in msg375376) can make it substantially easier for the Python side to protect itself, because it will be race-free without any locks.