"a better input"

[Alexis Layton]

[[ This message was both posted and mailed: see
   the "To," "Cc," and "Newsgroups" headers for details. ]]

> 
> To me, it seems that taking the input string and applying restricted
> evaluation (carefully pruning what builtins we want to allow or
> disallow -- indeed perhaps _enriching_ the set of normal builtins
> with e.g. functions from math...) would be satisfactory.  But that
> wouldn't meet your examples -- not only 2**22, but also list
> comprehensions would then surely be allowed.
> 
> If you can give better specs of what you want to allow and disallow
> (and ideally WHY...) then we may think about implementation (e.g.
> by compiling then perusing the bytecodes to see if anything that
> must not be allowed has slipped in).

What about allowing the following behavior for a "safe" input:
   read a line
   trim whitespace on both sides
   attempt to parse the string as a Python boolean, integer, real, or
complex* literal
   otherwise return a the string

*I realize there are no true complex literals, we'd have to do a little
extra work here

It to me seems that having a "safer" input is a less astonishing change
than eliminating it entirely.

-- 
Alexis Layton
alex AT post.harvard.edu