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:

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?

-CHB


--

Christopher Barker, Ph.D.
Oceanographer

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

Chris.Barker@noaa.gov