On Wed, Apr 22, 2020 at 7:40 PM Kyle Stanley <aeros...@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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EHU5DQJ53MNMQNUXHBL5HQ2B7CSWPRZI/ Code of Conduct: http://python.org/psf/codeofconduct/
