On 7 September 2017 at 20:14, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Thu, Sep 7, 2017 at 11:52 AM, Paul Moore <p.f.moore@gmail.com> wrote:
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.
Ah, OK. so if I create a new interpreter, none of the classes, functions, or objects defined in my calling code will exist within the target interpreter? That makes sense, but I'd missed that nuance from the description. Again, this is probably worth noting in the PEP. And for the record, based on that one fact, I'm perfectly OK with the initial API being string-only.
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.
This all sounds very reasonable. Thanks for the clarification. Paul