> If this race condition is a bug in gc, then we should fix that.

> If it is a bug in your code, surely you should fix that rather than disable gc.

It's neither: it is something related to the combination of some 3rd party libraries I'm using (if you're interested, I have described it here: https://github.com/paramiko/paramiko/issues/1634).

> Either way, I don't think we should complicate the gc iterface by adding a second way to enable and disable the cyclic gc.

I see what you're saying. I wasn't thinking of of this idea as complicating it, I had in mind existing interfaces which have these 2 sets of functions (for example, Linux's local_irq_enable/disable and local_irq_save/restore).

Another approach, only modifying the existing API in a compatible way, will be as follows:

    --- a/Modules/gcmodule.c
    +++ b/Modules/gcmodule.c
    @@ -1489,9 +1489,10 @@ static PyObject *
     gc_disable_impl(PyObject *module)
     /*[clinic end generated code: output=97d1030f7aa9d279 input=8c2e5a14e800d83b]*/
     {
    +    int was_enabled = gcstate->enabled
         GCState *gcstate = get_gc_state();
         gcstate->enabled = 0;
    -    Py_RETURN_NONE;
    +    return was_enabled ? (Py_INCREF(Py_True), Py_True) : (Py_INCREF(Py_False), Py_False);
     }

Then I can write code this way:

    foo():
        disabled = gc.disable()
        ....
        if disabled:
             gc.enable()

It can be taken ahead to change `gc.enable()` to `gc.enable(disabled=True)` so I can just call it as `gc.enable(disabled)`:

    foo():
        disabled = gc.disable()
        ....
        gc.enable(disabled)