[Python-Dev] PEP_215_ (string interpolation) alternative EvalDict

[Steven Majewski]

[ 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