On Tue, Nov 7, 2017 at 6:41 AM, Steven D'Aprano firstname.lastname@example.org wrote:
Also, it is unfortunate that `ast.literal_eval` is less accessible than `builtins.eval`. Giving it an alias in builtins might make it easier for programmers (and less scary - "ast" might sound like I need a PhD to use it).
I agree -- literal_eval is a really nice utility, but folks are not likely to find it...or think it's as simple a tool as it is...
In fact, a couple weeks ago, one of the students in my intro to python class used it -- good for him!), When my TA was reviewing the code (and she's a pretty experienced developer), she asked me:
what is the ast module?
I know it's the "Abstract Syntax Tree" module, so was very surprised that an intro student was messing about the the AST!
when I looked at the code, I saw, oh that's literal_eval -- a simple (seeming, anyway) function that a beginner may just want to use (good old stack overflow...)
I can see why liter_eval is needed in the AST module, but it's also a useful tool by itself,a nd that seems like a very strange place to store it...
In any case, I think that securing literal_eval is much simpler than
try: # a thousand character expression ought to be enough for # any legitimate purpose... value = literal_eval(tainted_string[:1000]) # untested except MemoryError: value = None
sure -- though I'd use a lot more than 1000 characters -- not much these days, and you might want to unpack something like a JSON data package...
And I'd raise an exception if it's too big, rather than trying to evaluate the subset...
Maybe something like this should be patched into it?