Steven Majewski wrote:
....
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.
I think you mean $" strings, not u" strings. Given: a = $"foo.bar: $foo.bar(abc, 5)" I can translate that *at compile time* to: a = $"foo.bar: %s" % foo.bar(abc, 5) No runtime evaluation is necessary. So I see no security issues here. On the other hand, evaldict really does have the same semantics as an eval, right? Probably it is no more or less dangerous if you only do a single level of EvalDict-ing. But once you get into multiple levels you could get into a situation where user-provided code is being evaluated. The first level of EvalDict incorporates the user-provided code into the string and the second level evaluates it. Ping's current runtime implementation does use "eval" but you could imagine an alternate implementation that actually parses the relevant parts of the string according to the Python grammar, and merely applies the appropriate semantics. It would use "." to trigger getattr, "()" to trigger apply, "[]" to trigger getitem and so forth. Then there would be no eval and thus way to eval user-provided code. Paul Prescod