[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