On Wed, Apr 22, 2020 at 7:40 PM Kyle Stanley <aeros167@gmail.com> wrote:
If there's not an implementation detail that makes this impractical, I'd like to give my +1 on the `Interpreter.run()` method returning values. From a usability perspective, it seems incredibly convenient to have the ability to call a function in a subinterpreter, and then directly get the return value instead of having to send the result through a channel (for more simple use cases).
The PEP only proposes the ability to run code (a string treated as a script to run in the __main__ module) in an interpreter. See PyRun_StringFlags() in the C-API. Passing a function to Interpreter.run() is out of scope. So returning anything doesn't make much sense.
Also, not that the API for subinterpreters needs to be at all similar to asyncio, but it would be consistent with `asyncio.run()` with regards to being able to return values. Although one could certainly argue that `asyncio.run()` and `Interpreter.run()` will have significantly different use cases; with `asyncio.run()` being intended as a primary entry point for a program, and `Interpreter.run()` being used to execute arbitrary code in a single interpreter.
While somewhat different, this is something we should keep in mind. -eric