A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2002-January/019469.html below:

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

[Python-Dev] PEP_215_ (string interpolation) alternative EvalDict [Python-Dev] PEP_215_ (string interpolation) alternative EvalDictPaul Prescod paul@prescod.net
Mon, 14 Jan 2002 17:33:07 -0800
Steven Majewski wrote:
> 
>...
> 
> Your right. I'm confusing PEP 215 with the discussion on PEP 215,
> where that feature was requested.
> 
> However, if you allow array and member access as well, which Paul
> suggests, then you open the security problem back up unless you
> do some code analysis (as he also suggests) to make sure that
> [index] or .member doesn't perform a hidden function call
> ( A virus infected __getitem__ for example. )

If you have a virus-infected __getitem__ you are screwed regardless. We
can't defend against that.

The whole point is that we are never evaluating code provided by the
user. "Safe" programmer-supplied literal strings are differentated at
compile time from arbitrary strings. The interpolation engine only works
on safe strings. Calling an overriden __getitem__ or .member is as safe
as if they had done it in the way they would today:

"%s" % foo.bar()

Think of it as pure, compile-time syntactic sugar. If you want it to act
like eval, I guess you would do this:

$"$(eval('....'))...."

which would compile to:

"%s" % eval('....')

 Paul Prescod



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