Home Original page

[Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

Paul Moore p.f.moore at gmail.com
Thu Sep 7 14:52:47 EDT 2017 
On 7 September 2017 at 19:26, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> As part of the multi-core work I'm proposing the addition of the
> "interpreters" module to the stdlib.  This will expose the existing
> subinterpreters C-API to Python code.  I've purposefully kept the API
> simple.  Please let me know what you think.

Looks good. I agree with the idea of keeping the interface simple in
the first instance - we can easily add extra functionality later, but
removing stuff (or worse still, finding that stuff we thought was OK
but had missed corner cases of was broken) is much harder.

>    run(code):
>
>       Run the provided Python code in the interpreter, in the current
>       OS thread.  Supported code: source text.

The only quibble I have is that I'd prefer it if we had a
run(callable, *args, **kwargs) method. Either instead of, or as well
as, the run(string) one here.

Is there any reason why passing a callable and args is unsafe, and/or
difficult? Naively, I'd assume that

    interp.call('f(a)')

would be precisely as safe as

    interp.call(f, a)

Am I missing something? Name visibility or scoping issues come to mind
as possible complications I'm not seeing. At the least, if we don't
want a callable-and-args form yet, a note in the PEP explaining why
it's been omitted would be worthwhile.

Paul
More information about the Python-ideas mailing list