"a better input"

[Alex Martelli]

Gareth McCaughan wrote:
        ...
>> To expand: we could really do with something that lets the user
>> enter "46" or "0x1234" or "'walrus'" or "-2+6j" or "[1,'a',{3:4}]"
>> and returns the same as |input| does for those, but that doesn't
>> permit "f(123)" or "2**2002" or "[x for x in [1,2,3]]".

You'll have to pin that down more closely, as I can't see any
easily definable difference between operators used as in:
        -2+6j
and operators used as in:
        2**6
yet apparently you want to allow the former but forbid the latter
(why? what is gained in forcing people to do this in their head?).

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).


Alex