[EMAIL PROTECTED] wrote:
> But those objections miss the point. Having had those troubles
> explained to me now, I'm still leaving my code unchanged - it still
> does what I mean. That is,
>
> eval(source, {'builtins': {}}) works enough like an evaluator of
> literals to let you duck the work of writing that evaluator until you
> need it. Yagni.
until you forget about it, and someone uses the security hole to take
down your company's site, or steal all the customer data from your
database, or some such thing.
I think the PHP "I don't really get bound parameters; let's explain how
to build SQL statements by hand first" shows that you should avoid doing
things in stupid ways in documentation that's likely to be read by
inexperienced programmers...
> eval(source, {'builtins': {}}) works enough like an evaluator of
> literals to l
eval(source, {'builtins': {}}) doesn't prevent you from using built-ins,
though. it's spelled __builtins__, not builtins:
>>> eval("len('10')", {"builtins": {}})
2
>>> eval("len('10')", {"__builtins__": {}}
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 1, in <module>
NameError: name 'len' is not defined
> That's useful, and likely an FAQ.
A FAQ that discusses good ways to handle Python-like literals and
expressions would definitely be a useful addition to the FAQ. if nobody
else does anything about it, I'll get there sooner or later.
</F>
--
http://mail.python.org/mailman/listinfo/python-list
