Related library: pure_eval about asteval HOT 4 CLOSED

@alexmojaki The initial commit to a git repository for asteval was in 2012: (see newville@67fb537). At that point, the code had existed for about a year or more, but was not yet using git - and I did not bother with svn-to-git for this code at that time. The library was already working pretty well and had some unit tests. Basically, the code was pulled out of a larger effort that eventually broke itself into separate libraries for asteval, lmfit, and my X-ray Analysis package xraylarch. By the end of 2012, there were contributions from others, documentation, continuous integration with Travis CI, and the asteval library was available on PyPI.

Perhaps it would have been helpful if you and the other authors of pure_eval had known about this library when starting pure_eval, though I'm not sure. From a quick look at the Readme, I'm not certain I understand the goals of pure_eval (is_expression_interesting? interesting to whom?). But, anyway, maybe there's some code here you all would find useful. Cheers!

from asteval.

The primary use case is to extract information from stack frames to be displayed in tracebacks or for other debugging or magic. For example it's used by stack_data in IPython and in sentry to show the values of some expressions alongside the variables in a frame.

In these cases the code is trusted, it's written by the user of pure_eval rather than external untrusted users. But the namespace can contain arbitrary objects meaning innocent-looking operations like attribute access could cause arbitrary side effects which are probably not malicious but still unwanted. Hence pure_eval will not evaluate rect.area in the README example because it can see area isn't in the __dict__ and it has no idea what getting that attribute might do.

By contrast, asteval is worried about problematic code, but it expects that the namespace is safe and under control, so it will happily call any function it can find.

It's a subtle enough difference that it took me a while to confirm that asteval doesn't actually fulfill pure_eval's use case, and someone coming across one of the two libraries might similarly take a while to realise that their use case actually requires the other (which they might not know exists yet).

is_expression_interesting is a side utility and not the main point of the library. It basically looks out for a few cases where the value of an expression is exactly what you'd expect if you looked at its source code and there's probably no point in showing that value to the user. The docs explain the precise cases.

from asteval.

@alexmojaki Yeah, I'm still sort of baffled by what you're doing (or trying to do), both with your code and in this Issue. For sure, if your "Rectangle" was remotely more complicated, accessing instance attributes could have side effects. Python is a dynamic language and neither the complexity nor the resources needed to access an object can be predicted easily from its name, or even really from its datatype. I'm sort of not getting the "here's what this code does" part. It might be that I can't really follow the code in your Readme -- the code snippets are incomplete.

Is this something that you think would be useful for asteval?

from asteval.

I don't have a real goal with this issue, nor do I suggest using pure_eval in asteval. I just thought you'd be interested in the library. The two libraries are similar enough that one might think they have the same goal. One day you might have someone asking you how to accomplish something with asteval and it'll turn out that asteval is wrong for them, what they need is pure_eval.

I would like to know what it is that isn't clear about the README. You give the library an AST node, it evaluates it if it knows it can do so without triggering side effects (i.e. calling user code) otherwise it raises an exception.

from asteval.