A "PyInterpreterState *interp" field on PyTypeObject would allow us to quickly access the originating interpreter from any object.  This will help us avoid more costly lookups.  The additional pointer used for this should not have a significant impact on the memory usage of CPython.

PEP 573 already proposes adding a pointer to the *module* to heap types (well, those that opt in).
We should rather add a pointer from *modules* to the interpreter state.

I think access to the global module state is the most critical for an extension, probably by far. A direct pointer to the interpreter state from every type feels like an optimisation that may be premature at this point. Modules should have that reference, though, as long as we assume a unique interpreter for each module instance (which we currently do).

How about you add a module state reference to the type object and a interpreter state reference to the module object?

> A "PyInterpreterState *interp" field on PyTypeObject would allow us to quickly access the originating interpreter from any object.

Does it mean that a type A created in interperter 1 can be seen/accessed from interpreter 2? First I understood that an interepter should only access objects created by itself?

> Does it mean that a type A created in interperter 1 can be seen/accessed from interpreter 2?

No, but it means that a type A *knows* that it was created in interpreter 1 without relying on the current thread local storage.

What it does with this information is totally independent :)

> How about you add a module state reference to the type object and a interpreter state reference to the module object?

Module state != module object, IIUC, but a chain like:

instance -> type -> module -> interpreter

would be feasible, if an extra step. Though that's only if PEP 573 makes it *compulsory* for heap types to contain a pointer to their module. Without a pointer to the interpreter state, an object could lose access to its memory (de)allocator (or its lock), depending on the model we eventually use to reduce reliance on the GIL in subinterpreters.

(Yes, this is one step in the direction of reducing the impact of the GIL, as well as reducing the tight coupling between native threads and Python threads, which is a huge pain point for embedders.)

> only if PEP 573 makes it *compulsory* for heap types to contain a pointer to their module

And that's impossible without either breaking API (or some hackery).
PyType_FromSpec doesn't get the information, and it can be easily outside module initialization.

One possibility is to attach the __main__ module (or sys, or some synthetic module) to "module-less" classes, just to have something interpreter-specific there. But at that point, a dedicated "PyInterpreterState *" field starts looking like a better alternative.
It does complicate the "chain":

instance --> type -?> module --> interpreter
               |                   ^
               '-------------------'

But, one more thing that we need to think about is static types. Those are shared across interpreters; the "PyInterpreterState *" field should only be added to PyHeapTypeObject. ISTM that until we phase out static types entirely, you can't get the interpreter by following pointers from a type/instance anyway.
At that point, the opt-in approach of PEP 573 starts looking more attractive again:

instance --> type -?> module --> interpreter

> No, but it means that a type A *knows* that it was created in interpreter 1 without relying on the current thread local storage.

What's wrong with _PyInterpreterState_GET_UNSAFE()?

This macro is based on _Py_atomic_load_relaxed(&_PyRuntime.gilstate.tstate_current).

If this atomic variable is an issue, do we need a better solution to get the current thread state and get the current interpreter?

Which kind of code pattern is supposed to be more efficient if it would be possible to get a "PyInterpreterState *" from a "PyTypeObject*"? I don't understand which problem this issue is supposed to solve.

I close the issue.