Optional Flag to Prevent Python Code Execution

[joelonsql]

Review Mojo's priorities

• [X] I have read the roadmap and priorities and I believe this request falls within the priorities.

What is your request?

I am requesting an optional flag (--no-python) to be added to the mojo command that prevents any Python code from being imported or executed, recursively.

What is your motivation for this change?

As a Rust user, I find Mojo very interesting, especially the ASAP Destructor concept. However, I am concerned about the possibility of unintended Python code execution. This feature would be valuable for projects that want to ensure 100% Mojo code at all levels from the start.

Any other details?

This flag would be particularly useful for new projects aiming for a pure Mojo codebase, providing peace of mind that no Python code will run inadvertently.

[joelonsql]

Alternative idea: How about a new decorator, @nopython, to indicate per struct that it is recursively pure Mojo 🔥?

[joelonsql]

Or maybe @pure? Sounds more enthusiastic, saying no to things is boring.

[joelonsql]

Maybe this falls under some other more general concept in Mojo that has not been designed yet, such as an effect system?

	EXCEPTIONS	IO
DYNAMICALLY TYPED & DYNAMICALLY SCOPED	panicking	blocking
STATICALLY TYPED & DYNAMICALLY SCOPED	checked exceptions	IO effect
STATICALLY TYPED & LEXICALLY SCOPED	Result	async/await

Table from this article: https://without.boats/blog/coroutines-and-effects/

[joelonsql]

I realize my previous comment on effect systems unnecessarily broadened the scope.

In general, I would like a compile-time mechanism to recursively restrict what modules that can be imported.

Specifically, to allow Python code from executing, the "python" module would need to be explicitly allowed at top-level.

In Rust, I'm often concerned about dependencies having recursive dependencies, resulting in a huge list of indirectly used modules. This is worrisome, not only because of the volume of code but also because I lack control over these modules' activities. Are they accessing my file system? Can they execute executables on disk? Do they perform network access? This requires me to trust the authors and their dependencies implicitly.

As a Mojo user, it would be nice if this situation could be improved. Imagine if, at the top level of a program, we could globally control what low-level APIs all imported modules, directly or indirectly, have access to.

For most users, a good default might be allowing everything ("*"), while more paranoid users like myself might prefer fine-grained control.

If, upon upgrading a Mojo library in my application, it suddenly required network access, I would prefer to receive a compilation error detailing the disallowed low-level API.

I don't have clear ideas on syntax/semantics though.

Thoughts?

[jon-chuang]

@joelonsql what is the relationship between fn, @parameter and @nopython?