> While the semantics are different, the result is similar and
> the actual numbers used are usually determined by experiment
> or rough estimate - noone expects the APIs to provide any kind
> of exact timing and it's not needed either.

There's no reasonable formula for computing an absolute switching
interval from the current "check interval" number. Besides, as I said,
there's no demonstrated reason to change the interval with the new GIL.

> * they don't use any threads and thus don't need to check
> for other threads at all or only rarely: in such a case they
> use a large check interval number

Well, if you don't use any threads you don't have to change the setting
in the first place :-). You might want to do it in order to
"micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
is unnecessary with the new GIL, since the interval is ignored when
there's only one thread running.

> Turning the existing APIs into no-ops is certainly not a good
> idea, since that will change application performance for both
> use cases.

The new GIL will change performance far more anyway. Trying to simulate
the old behaviour is doomed to failure. If we want to keep the current
performance characteristics, we'd better not backport the new GIL (which
I'm fine with by the way).