> Can you please provide an example of what user would do and what
> changes existing extension modules would need to make?

The patch contains such a change for ctypes. It's quite simple actually.

> By default stuff would work on the main interpreter, but if for a
> specific thread it wanted to operate in context of a different sub
> interpreter, would call PyInterpreterState_Swap() to indicate that.
> That would store in TLS outside of any existing data structures.
> Functions like existing PyGILState_Ensure()/PyGILState_Release() would
> then look up that TLS variable to know which interpreter they are
> working with.

That sounds like an ugly hack to avoid passing the desired interpreter
state directly to PyGILState_Ensure()/PyGILState_Release().

Besides, it will only work if a thread always serves the same
sub-interpreter.

> Doing it this way meant that no C extension modules using
> PyGILState_??? functions would need to change at all, as what
> interpreter is being operated on dictated by who created the thread
> and initiated call in to Python interpreter.

Who would do that, if it's not the extensions in question?
"who created the thread" is often a third-party library (e.g. sqlite)
that has no notion of a Python interpreter. That's the whole point of
using the PyGILState_* API, really. So extensions *will* have to be
fixed.

> That you are saying that sqlite needs changes is what makes me things
> the way you are going is a problem. It isn't practical to make SWIG
> change to use something other than
> PyGILState_Ensure()/PyGILState_Release(), it should be transparent and
> required no changes to existing C extensions.

What does SWIG use them for?