Summary

As far as I have seen, RustPython is not yet suitable for "safe" embedding, meaning that executed Python code can block or hurt the caller code, because:

• execution can loop forever,
• memory allocation is not bounded,
• import cannot be disabled.

Detailed Explanation

I wish to use RustPython as a scripting language within a game engine, running third-party user code. A requirement for me is that this code is run in a safe way. As far as I have seen (but I might have missed some elements), it is currently not the case:

• It is not possible to limit code execution up to a maximum number of instructions. Looking into RustPython's source, if I'm not mistaken, this feature would need to be added to ExecutingFrame in its execution loop. Maybe the ExecutionResult type could be extended with an InstructionBudgetExceeded variant or similar (which could later be expanded to support step by step interactive debugging).
• I couldn't find a way to set limits to heap allocation or stack size, that would also be needed.
• My understanding is that importlib is always enabled, but that the OS module is currently disabled in Wasm32 or Wasi, is that correct? If so, there should be a way to have finer-control on import lib or even forbid user-defined import statements altogether. Also, I see no reason to link the control of the availability of the os module to WASM, maybe a feature flag would be a good addition. Similarly, it should be possible to not enable some Windows specific code and fully disable or controls IOs (including network) and side-effect functions (such as delay) regardless of the target platform.
• Control of the garbage collection would be welcome ((READY FOR REVIEW)Garbage collect: A stop-the-world cycle collector #4180), although not critical because one design could be that the RustPython context does not outlive a display frame.

Drawbacks, Rationale, and Alternatives

The rationale is to use RustPython as an embedding language within larger software, such as game engines. In these, the software must fully control the scripting environment's limits.

The main drawback is increased code complexity within RustPython, but I believe it can be done cleanly, with some work of course. The split of the Std library (#3102) was already a step towards the direction of embedding.

The alternatives are to not implement this feature, or do it in a fork. A similar issue exists (#3090), but it is more of a question, so I thought an RFC-style new issue is better.

Unresolved Questions

There are quite some design questions obviously, but I guess first one should agree whether this overall feature makes sense for the project, then the design can be worked out. Probably a unified way to control embedding would be elegant.