PyOS_InputHook and PyOS_ReadlineFunctionPointer are globally-registered input hooks that have no way of recovering module-level state for the extensions that registered them. In practice, extensions like readline and tkinter get around this by using global state, which obviously isn't subinterpreter-friendly.
What's more, extensions without advertised subinterpreter support (like readline and tkinter) who register these hooks might find themselves called from within a subinterpreter (where their extension hasn't even been loaded). That's definitely a situation we want to avoid.
It seems like the best solution for 3.12 is to only call these hooks from the main interpreter, which makes the bad situation quite a bit better. If libraries really need better APIs that work per-interpreter and have ways to access module state, we can certainly add them later (but for now maybe we'll just cross our fingers and hope that nobody actually cares).
@ericsnowcurrently, how does this sound to you?
Linked PRs
PyOS_InputHookandPyOS_ReadlineFunctionPointerare globally-registeredinputhooks that have no way of recovering module-level state for the extensions that registered them. In practice, extensions likereadlineandtkinterget around this by using global state, which obviously isn't subinterpreter-friendly.What's more, extensions without advertised subinterpreter support (like
readlineandtkinter) who register these hooks might find themselves called from within a subinterpreter (where their extension hasn't even been loaded). That's definitely a situation we want to avoid.It seems like the best solution for 3.12 is to only call these hooks from the main interpreter, which makes the bad situation quite a bit better. If libraries really need better APIs that work per-interpreter and have ways to access module state, we can certainly add them later (but for now maybe we'll just cross our fingers and hope that nobody actually cares).
@ericsnowcurrently, how does this sound to you?
Linked PRs
PyOS_*hooks in subinterpreters #104674