Python - Zelle book uses eval(), is it wrong?

Question

PLEASE NOTE: This is NOT about the use of eval(), it is about the potential quality (or lack thereof) of a book it is used and taught in. SO already has countless threads ab

Answer 1

Yes, it's wrong. But I think I know why it's in there.

Lots of people use input() in Python 2.x, which is a very unfortunately named function since it doesn't just read input, it also evaluates it. The converter 2to3 converts each use of input() to eval(input()), as you can see:

$ cat test.py
x = input("Enter your number: ")

$ 2to3 test.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: Refactored test.py
--- test.py     (original)
+++ test.py     (refactored)
@@ -1 +1 @@
-x = input("Enter your number: ")
+x = eval(input("Enter your number: "))
RefactoringTool: Files that need to be modified:
RefactoringTool: test.py

So my guess is that it is just a little sloppy. From the Amazon description:

This is the second edition of John Zelle's Python Programming, updated for Python 3.

I think someone ran 2to3 on all of the code samples without checking the output thoroughly enough. So yes, it was a mistake to use input() in Python 2.x, and it was a mistake to use 2to3 without checking the output.

Answer 2

Well, to combine eval() and input() in such a way creates a rudimentary but possibly very harmful 'shell'. I haven't read the book, but I'd take it with a grain of salt. It's not just bad practice, it implements one deadly combo of functions.

Answer 3

As the author of the book in question, let me weigh in on this issue.

The use of eval in the book is largely a historical artifact of the conversion from Python 2 to Python 3 (although the same "flaw" exists in the use of input in Python 2). I am well aware of the dangers of using eval in production code where input may come from an untrusted source, but the book is not about production code for a web-based system; it's about learning some CS and programming principles. There's really nothing in the book that could be remotely considered production code. My goal is always to use the simplest approach that allows me to illustrate the point I am trying to make, and eval helps to do that.

I do not agree with the crowd proclaiming eval evil in all contexts. It's very handy for simple programs and scripts that are only being run by their writer. In that context, it's perfectly safe. It allows for simple multiple inputs and expressions as input. Pedagogically, it emphasizes the concept of expression evaluation. Eval exposes all the power (and danger) of an interpreted language. I use eval all the time in my own personal programs (and not just in Python). In hindsight, I absolutely agree that I should have included some discussion of the potential risks of eval; this is something I always do in my classes, anyway.

The bottom line is that there are numerous ways this book could be improved (there always are). I don't think using eval is a fatal flaw; it is appropriate for the types of programs being illustrated and the context in which those programs appear. I am not aware of any other "insecurities" in the way Python is used in the book, but you should be warned (as the Preface explains) that there are numerous places where the code is not exactly "Pythonic."

Answer 4

Yes eval should be spelled evil instead to warn people about this ;) You should try and never use it unless you absolutely have to. In this case it's intuitive to use int() instead, it's even much more readable! Also if you really had to you could use ast.literal_eval (it only evaluates literals as the name implies, so it won't allow the user to run malicious code) which is actually safe, but there is no need for this and there is no need for eval() in this case.

Answer 5

Since eval is so out of place and unnecessary in the example you give, I would certainly have doubts about the safety of other parts of the book. Is the author going to suggest that you append a user entered string to a SQL query?

I think it could be worth finding the author's email address and asking him about it directly.