Add documentation for Interpreter constructor parameters about asteval HOT 5 CLOSED

@fpischedda Thanks. Yes, the documentation for the API definitely needs work!

FWIW, I think the max_time is sort of unreliable for many potential problems, especially if evaluation of a single operation takes a very long time. Using a separate monitoring process is probably necessary for such problems, though it may well depend on the context. It might be that using multiprocessing could provide a better "kill process if max execution time is exceeded", but I have not explored this in any detail.

from asteval.

@newville I'm building a web app in which the "admin" can customize some of the site behaviour writing python code snippets using the admin panel and this clearly depends a lot on asteval; what do you mean when you say "I think the max_time is sort of unreliable for many potential problems"? what are the kind of problems that you think I should look for?

p.s. I don't know if this is the right place to discuss such topics so if you prefere we can move somewhere else...or close the discussion :) ?

from asteval.

@fpischedda As an example using numpy.linspace: In plain python, you'll see that

from numpy import linspace
linspace(1, 100, 1e3)    # no noticeable delay
linspace(1, 100, 1e6)    # slight delay, not bad if that's what you need to do
linspace(1, 100, 1e9)    # noticably slow
linspace(1, 100, 1e12)   # probably take all day

Even in python, Ctrl-C will take a long time to interrupt this call. The thing is, this happens in C, and in a single call. In asteval, it happens all within the call to the actual function (linspace) inside Interpreter.on_call().

Similarly,

x =9**5**5   # < 0.1 sec 
y =5**9**9   #  > 10 sec 

It's very hard for the Interpreter itself to say "I've been running this function too long", because execution never actually gets back to the Interpreter at all until the function is complete. You really need something monitoring the process. And the examples show that there's essentially no way for the interpreter to predict run time.

But, I think that is what you really care about anyway -- not so much that the evaluation of a single node is taking too long, but that the process is hung.

from asteval.

@newville Thanks for the clarification, now I understand what you meant; fortunately the slowest parts of the code will be those accessing a (remote, slow) database but when it will be in production (or staging) this problem should disappare

from asteval.

fixed with 0.9.9

from asteval.