Home Original page

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

Eric Snow ericsnowcurrently at gmail.com
Thu Sep 7 15:14:19 EDT 2017 
On Thu, Sep 7, 2017 at 11:52 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 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)

The problem for now is with sharing objects between interpreters.  The
simplest safe approach currently is to restrict execution to source
strings.  Then there are no complications.  Interpreter.call() makes
sense but I'd like to wait until we get feel for how subinterpreters
get used and until we address some of the issues with object passing.

FWIW, here are what I see as the next steps for subinterpreters in the stdlib:

1. add a basic queue class for passing objects between interpreters
    * only support strings at first (though Nick pointed out we could
fall back to pickle or marshal for unsupported objects)
2. implement CSP on top of subinterpreters
3. expand the queue's supported types
4. add something like Interpreter.call()

I didn't include such a queue in this proposal because I wanted to
keep it as focused as possible.  I'll add a note to the PEP about
this.

>
> 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.

I'll add a note to the PEP.  Thanks for pointing this out. :)

-eric
More information about the Python-ideas mailing list