[ python-Bugs-215126 ] Over restricted type checking on eval()
function
SourceForge.net
noreply at sourceforge.net
Mon Jan 12 17:01:49 EST 2004
Bugs item #215126, was opened at 2000-09-22 15:36
Message generated for change (Comment added) made by mcherm
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470
Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: Later
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Over restricted type checking on eval() function
Initial Comment:
The built-in function eval() takes a string argument and a dictionary. The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries.
The following example creates a type error:
eval, argument 2: expected dictionary, instance found
class SpreadSheet:
_cells = {}
def __setitem__( self, key, formula ):
self._cells[key] = formula
def __getitem__( self, key ):
return eval( self._cells[key], self )
ss = SpreadSheet()
ss['a1'] = '5'
ss['a2'] = 'a1*5'
ss['a2']
----------------------------------------------------------------------
Comment By: Michael Chermside (mcherm)
Date: 2004-01-12 17:01
Message:
Logged In: YES
user_id=99874
Hmm... I like this!
Of course, I am wary of adding *yet another* special double-
underscore function to satisfy a single special purpose, but
this would satisfy all of *my* needs, and without any
performance impact for lookups that are FOUND. Lookups that
are NOT found would have a slight performance degrade (I
know better than to speculate about the size of the effect
without measuring it). I'm not really sure what percentage of
dict lookups succeed.
At any rate, what are these "other contexts" you mention in
which a __keyerror__ would "also be useful"? Because if we
can find other places where it is useful, that significantly
improves the usefulness.
OTOH, if the tests can be done ONLY for eval (I don't really
think that's possible), then I'm certain no one cares about the
performance of eval.
----------------------------------------------------------------------
Comment By: Gregory Smith (gregsmith)
Date: 2004-01-12 14:38
Message:
Logged In: YES
user_id=292741
This may be a compromise solution, which could also be
useful in other contexts: What if the object passed
is derived from dict - presumably that doesn't help
because the point is to do low-level calls to the
actual dict's lookup functions.
Now, suppose we modify the basic dict type, so
that before throwing
a KeyError, it checks to see if it is really a derived
object with a method __keyerror__, and if so, calls
that and returns its result (or lets it throw)?
Now you can make objects that look like dicts, and
act like them at the low level, but can automatically
populate themselves when non-existent keys are requested.
Of course, __keyerror__('x') does not have to make
an 'x' entry in the dict; it could make no change, or
add several entries, depending on the desired semantics
regarding future lookups. It could be set up so that
every lookup fails and is forwarded by __keyerror__ to
the __getitem__ of another object, for instance.
The cost of this to the 'normal' dict lookup is that
the need to do PyDict_CheckExact() each time
a lookup fails.
----------------------------------------------------------------------
Comment By: Michael Chermside (mcherm)
Date: 2003-12-16 10:37
Message:
Logged In: YES
user_id=99874
I'll just add my voice as somebody who would find this to
be "darn handy" if it could ever done without noticably
impacting the speed of python code that DOESN'T use eval().
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2000-09-23 00:18
Message:
Added to PEP 42.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2000-09-22 15:42
Message:
Changed Group to Feature Request. Should be added to PEP 42 (I'll do that if nobody beats me to it).
CPython requires a genuine dict now for speed. I believe JPython allows any mapping object.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470
More information about the Python-bugs-list
mailing list