On Wed, 29 Apr 2020 at 02:26, Eric Snow <ericsnowcurrently@gmail.com> wrote:
Subinterpreters run all Python code right now. I'm guessing by "general python code" you are talking about the code folks are writing plus their dependencies. In that case, it's only with extension modules that we run into a problem, and we still don't know with how many of those it's a problem where it will take a lot of work. However, I *am* convinced that there is a non-trivial amount of work there and that it impacts large extension modules more than others. The question is, what can we do to mitigate the amount of work there?
One thing that isn't at all clear to me here is that when you say "Subinterpreters run all Python code", do you *just* mean the core language? Or the core language plus all builtins? Or the core language, builtins and the standard library? Because I think that the vast majority of users would expect a core/stdlib function like subinterpreters to support the full core+stdlib language. So my question would be, do all of the stdlib C extension modules support subinterpreters[1]? If they don't, then I think it's very reasonable to expect that to be fixed, in the spirit of "eating our own dogfood" - if we aren't willing or able to make the stdlib support subinterpreters, it's not exactly reasonable or fair to expect 3rd party extensions to do so. If, on the other hand, the stdlib *is* supported, then I think that "all of Python and the stdlib, plus all 3rd party pure Python packages" is a significant base of functionality, and an entirely reasonable starting point for the feature. It certainly still excludes big parts of the Python ecosystem (notably scientific / data science users) but that seems fine to me - big extension users like those can be expected to have additional limitations. It's not really that different from the situation around C extension support in PyPy. Paul [1] Calling threading from a subinterpreter would be an interesting test of that ;-)