Restrictions beyond Interpreter(use_numpy=False, minimal=True)

[cackovic]

I would like to restrict Interpreter more than what Interpreter(use_numpy=False, minimal=True) allows. For instance, I want to restrict slice in asteval.asteval.ALL_NODES or I want to restrict dir in asteval.astutils.FROM_PY.

Interpreter.__init__() only supports restricting the objects that are specifically defined in the __init__. While I can monkeypatch asteval and get the functionality I want, I think it would make more sense to explicitly support overriding asteval.asteval.ALL_NODES and all of the other globals that are defined in asteval.astutils.

Are there any objections to allowing the user to pass in these globals to Interpreter.__init__()? This could also be done similar to Interpreter.remove_nodehandler() by having an Interpreter.remove_sym() that would remove entries from Interpreter.symtable.

Input is appreciated.

[newville]

@cackovic Sure, I guess that would be OK to all restricting more node types. There are 41 node types in ALL_NODES, but Interpreter only lets 12 of those get turned off. I think those are the most prone to potential abuse, but that may not be the only reason to turn them off. I think the main question would be how to expose the option to turn off other nodes. Would adding an option of no_slice=False be enough? I don't completely know how many nodes could be removed and still leave a working interpreter.

Similarly, FROM_PY, FROM_MATH, and FROM_NUMPY are sort of hardwired (can be monkey-patched but that's kind of ugly). But, do you have a suggestion for how to make that better? Like, we could add optional from_py=None, from_math=None, from_numpy=None options to Interpreter() that can be used to give a complete list of names to import from each module.

Anyway, adding options like that would be OK with me.

[cackovic]

My use case is not executing arbitrary code, but creating a Python-based DSL. I want to remove some nodes because they aren't needed in my case and never want to allow the user to be able to use them. I send an email to the address on your github account that included more specific (private) information on my use case.

I think that adding more parameters like no_slice makes the signature a little verbose. I would rather be able to pass in my own from_py (whitelisting) or maybe even an exclude_from_py (blacklisting). I think that if a user passes in one of the from_* parameters, it would be up to the user to determine if the interpreter works for their needs. My current use case has quite a lot turned off and is working well.

we could add optional from_py=None, from_math=None, from_numpy=None options to Interpreter()

This is exactly what I have done and I think that makes a lot of sense. Of course, keeping the old signature for compatibility would be important for existing users.

Please see the email I sent for additional context.

[newville]

I think this is now significantly more flexible with 0.9.30, and will close as being outdated and "probably better enough", if not "definitely solved to everyone's satisfaction".