[ 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4