[ Oops. Initial subject line said incorrectly PEP 216] On Mon, 14 Jan 2002, Paul Prescod wrote:
[...] As PEP 215 mentions, this also has advantages for reasoning about security. If I tell a new programmer to avoid the use of "eval" unless they consult with me, I'll have to tell them to avoid EvalDict also. My usual approach is to consider eval and exec to be advanced (and rarely used) features that I don't even teach new programmers.
But if you're going to allow interpolation of the results of arbitrary function into a string, it's going to be a security problem whether or not you use 'eval' to do it. My code hides the eval in the object's python code. u" strings would hide the eval in the C code. How is one more or less secure than the other. The security issue seems to be an argument for a non-language-syntax implementation, as it means that: the hidden eval's could be controlled with a restricted execution environment. ( Also the same advantages I cited to easily experiment with alternatives -- we could roll out a solution without having to tackle the security issue right away.) Also, although I agree with most of your other comments on making it simple and easy, the security issue argues against making it TOO simple. For example, I was considering making the current namespace of the call a default, so you wouldn't need globals() -- but I was worried that because of security and other issues, maybe that was too much "magic" . I think maybe how much magic is enough and how much is too much is one of the issues to discuss. Thanks for expanding on your initial comment. I think you're right that it needs to be simpler. But, for several reasons, security among them, I'm still -1 on PEP 215. -- Steve