Restrictions beyond Interpreter(use_numpy=False, minimal=True) about asteval HOT 3 CLOSED

@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.

from asteval.

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.

from asteval.

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".

from asteval.