On Tue, Nov 7, 2017 at 6:41 AM, Steven D'Aprano <steve@pearwood.info> 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
securing eval:

    # 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?



Christopher Barker, Ph.D.

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception