I use the following class to easily store data of my songs.
class Song: """The class to store the details of each song""" attsToStore=('Name', 'Artist', 'Album', 'Genre', 'Location') def __init__(self): for att in self.attsToStore: exec 'self.%s=None'%(att.lower()) in locals() def setDetail(self, key, val): if key in self.attsToStore: exec 'self.%s=val'%(key.lower()) in locals()
I feel that this is just much more extensible than writing out an
if/else block. However, I have heard that
eval is unsafe. Is it? What is the risk? How can I solve the underlying problem in my class (setting attributes of
self dynamically) without incurring that risk?
eval is a bad practice. Just to name a few reasons:
- There is almost always a better way to do it
- Very dangerous and insecure
- Makes debugging difficult
In your case you can use setattr instead:
class Song: """The class to store the details of each song""" attsToStore=('Name', 'Artist', 'Album', 'Genre', 'Location') def __init__(self): for att in self.attsToStore: setattr(self, att.lower(), None) def setDetail(self, key, val): if key in self.attsToStore: setattr(self, key.lower(), val)
There are some cases where you have to use
exec. But they are rare. Using
eval in your case is a bad practice for sure. I’m emphasizing on bad practice because
exec are frequently used in the wrong place.
Replying to the comments:
It looks like some disagree that
eval is ‘very dangerous and insecure’ in the OP case. That might be true for this specific case but not in general. The question was general and the reasons I listed are true for the general case as well.
eval is weak, not a clearly bad practice.
It violates the “Fundamental Principle of Software”. Your source is not the sum total of what’s executable. In addition to your source, there are the arguments to
eval, which must be clearly understood. For this reason, it’s the tool of last resort.
It’s usually a sign of thoughtless design. There’s rarely a good reason for dynamic source code, built on-the-fly. Almost anything can be done with delegation and other OO design techniques.
It leads to relatively slow on-the-fly compilation of small pieces of code. An overhead which can be avoided by using better design patterns.
As a footnote, in the hands of deranged sociopaths, it may not work out well. However, when confronted with deranged sociopathic users or administrators, it’s best to not give them interpreted Python in the first place. In the hands of the truly evil, Python can a liability;
eval doesn’t increase the risk at all.
Yes, it is:
Hack using Python:
>>> eval(input()) "__import__('os').listdir('.')" ........... ........... #dir listing ...........
The below code will list all tasks running on a Windows machine.
>>> eval(input()) "__import__('subprocess').Popen(['tasklist'],stdout=__import__('subprocess').PIPE).communicate()"
>>> eval(input()) "__import__('subprocess').Popen(['ps', 'aux'],stdout=__import__('subprocess').PIPE).communicate()"