[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

2019-09-27 Thread STINNER Victor
STINNER Victor added the comment: > 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

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

2019-09-27 Thread Petr Viktorin
Petr Viktorin added the comment: > 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

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

2019-09-26 Thread Steve Dower
Steve Dower added the comment: > 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

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

2019-09-26 Thread STINNER Victor
STINNER Victor added the comment: > 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

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

2019-09-26 Thread Christian Heimes
Christian Heimes added the comment: How about you add a module state reference to the type object and a interpreter state reference to the module object? -- nosy: +christian.heimes ___ Python tracker

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

2019-09-26 Thread Tahia K
Change by Tahia K : -- nosy: +ta1hia ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

2019-09-13 Thread Stefan Behnel
Stefan Behnel added the comment: 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,

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

2019-09-13 Thread Petr Viktorin
Petr Viktorin added the comment: 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. -- ___ Python tracker

[issue38160] Add a "PyInterpreterState *" field to PyTypeObject.

2019-09-13 Thread Eric Snow
New submission from Eric Snow : 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