Tools
DSPy adds LocalInterpreter, a persistent CPython worker that the release notes explicitly refuse to call a sandbox
`dspy.LocalInterpreter`, added in 3.4.0b1 via PRs #10238 and #10379, runs generated Python in a persistent subprocess using the current Python executable, giving ordinary Python compatibility without Deno while separating the worker's memory, stdout and lifecycle from the DSPy process. The notes state plainly that it is not a security sandbox: generated code keeps the host user's filesystem, environment, credentials, subprocess and network access, and the default `PythonInterpreter` is unchanged. `execution_timeout` counts host-tool time and kills the worker when exceeded but cannot stop a running host callable, whose result is simply discarded.
Source
↳ Follow the thread