Let me begin this review with a plea to all intending writers of books about the very excellent Python programming language; please stick the spam where the sun don't shine. And the parrots too. I loved the Monty Python series but after a couple of hundred pages these 'witty' references don't seem funny any more.
My headline for this review is very harsh but I am going to try to justify it in view of the very contrasting reviews this book has had. I am not a complete beginner but I am not a pro either, just a hobby programmer.
I bought this book under the influence of the many positive reviews and as I started to read it I was favourable impressed; it was interesting and clearly written. After a couple of evenings, however, I began to feel tired and puzzled; tired after trying to absorb several chapters of information and puzzled because I was no nearer to writing Python code than when I first opened the book. Eventually I realised what the problem was. The book explains clearly how things work but you have to be comfortable with the technical vocabulary used. There are very few example of how to do useful things with Python and this is a serious fault in the book. Instead of example programs there are little experiments on the command line to illustrate how things work. The first example program appears on page 393. Yes, that's page three hundred and ninety three, over a third of the way into the book!
The author's experience as a teacher shows itself in good ways and in bad ways. First, his explanations are usually clear and easy to follow but I feel that his approach and his choice of vocabulary are too technical for the beginning programmer. Second, he tries to reinforce and emphasize certain subjects by use of the standard pedagogical technique of repetition. This is fine in a class room situation. In a book, though, it is not required. It makes this big book even bigger with no benefit to the reader. For example, polymorphism and operator overloading are discussed briefly on page 84 in the context of strings and again on page 114 in the chapter about numbers, there are a couple more pages in the chapter on functions and several mentions in the chapters about object oriented programming. This could be justified if polymorphism were actually used, with examples, in these early mentions but it is not. These early mentions of polymorphism do not help the me use strings or numerical types, and they do not help with understanding the example programs (because there aren't any). In fact, they just get in the way. It seems the author feels (rightly) that they are important and so (wrongly, in my view) brings them up at every opportunity.
The few code samples are often hard to follow because common computer terms, such as value and data, are used as variable names. For example, on page 629, the class, FirstClass has the line, self.data = value. With a more realistic context, such as a CD collection or an employee class, it would be easier to distinguish the language constructs from the data that the code is working on and so the code would be easier to understand. As it is, even these trivial examples make the function of the code harder to discern.
Here are a couple of cases where I feel the approach is wrong and does not consider the needs of the learner. First, while trying to understand how to use the self argument I consulted pages 619-620, 640, and 686-687, scattered over 4 chapters. I found no clear explanation of how to use it but I found this on page 620: "Because classes are factories for multiple instances, their methods usually go through this automatically passed-in self argument whenever they need to fetch or set attributes of the particular instance being processed by a method call." Second, on the subject of lambda functions, on page 476 the explanation begins, "Besides the def statement, Python also provides an expression form that generates function objects. Because of its similarity to a tool in the Lisp language, it's called lambda. Like def, this expression creates a function to be called later, but it returns the function instead of assigning it to a name." These two samples are clearly written but, in my opinion, if you can understand them then you probably do not need this book. Faced with such prose, the beginner's only hope is the example code but often there isn't any.
This approach, of writing about how Python works, makes the book far longer than it needs to be. There are four chapters on functions! And the first three of them are on the basics. I have read books that cover this in one chapter including example code. They can do this because they tell you how to use functions rather than the technical details about how they work. For example, If you are coming to Python from C, like I did, then you may not realize that you have to define your functions in your code before you call them. This point is not stated! Instead there is a small section called "def is executable code" which might convey this point to an experienced programmer but which beginners will step over as they hunt for information about how to actually use functions.
The book contains a great deal of information and it might have done duty as a reference book if it had a good index. Unfortunately it has a bad index which is incomplete, inaccurate, and inconsistent. Some words which I tried without success to look up are, strip() method, argv, sys.argv, != operator, equality, NOT, arithmetic, OR, NOT, logical operators, ord. Examples of terms which are in the index but which have inaccurate or missing page references include the following. "self argument" is missing some important references on pages 640 and 619 - 620 while the single reference given, 687, is out by one page. "end of line characters 923" is out by one page and is missing pages 234-235. "file iterators 354" gives only the start page of the discussion and is missing a reference on page 235. Strangely, page 235 does appear as a subheading under "files" while page 354 does not.
There are no cross-references and in a book of this complexity there really should be. For example, the heading "anonymous functions" should have a "see also lambda expressions".
The index uses subheadings and sub-subheadings but there are no continuation headings with the result that when you scan from one column to the next it is difficult to know which level of the hierarchy you are in.
There are some rather weird headings that nobody would think of looking up. Sometimes they turn out to be section headings. Now it is quite reasonable to look at section headings for possible index terms but they are not always suitable as they stand because authors sometimes indulge in a little whimsy when choosing headings. For example under "arguments" I found "min wakeup call 455". This gives no clue as to the content to be found at page 455 so it should not be used in the index. A more descriptive heading should have been chosen instead.
Apart from the errors and omissions the index is badly in need of editing to make it consistent and coherent. The heading "comparison methods 730" is immediately followed by "comparison operators 730" while some pages on comparison operators (118-119 and 246-248) are not mentioned at all. Information about strings appears under "string exceptions", "string methods", "string formatting", "string formatting method calls" (yes, it's the next main heading), "string object type", "string operations" and finally "strings", the latter having a long column of subheadings which include some, but not all, of the pages listed under the earlier headings. Now it's a basic principle of indexing that if you find a word in the index then all the relevant and useful page references should be listed under that word. So under the heading "strings" should be everything about strings. But there is too much; that's why these other headings are used. So what lies under "strings"? Most of it belongs under a heading such as "string encoding" . A little editing would tidy this up and remove the rather silly "non-ASCII text, coding 907" followed immediately by "non-ASCII text, encoding and decoding 907", not to mention the subheading, "string methods 84", one page, while there are a dozen subheadings about string methods further back!
I could carry on ripping apart almost every part of the index but you are probably fed up with this by now. Why make such a fuss about the index? If you had tried to use this one you would think that indexes are rather useless and not worth the bother. But they are not supposed to be. A good index would direct you at once to the information on whatever topic you are looking for; not to every single mention as the search function on a PDF or e-reader does but just to the useful ones. This is a big, complex book with lots of intricate technical details so indexing it would be a considerable challenge requiring time and expertise. It would have rescued some value from the book.
You won't learn to program in Python from this book for the simple reason that the it does not try to teach it. It contains a huge amount of technical information about how Python works but not enough about how to actually use it. The author can write clearly and well in a way that makes it interesting but serious thought needs to be given to the organization of this large book and to targeting it to its intended audience. The back cover makes clear that it is an introductory level text which requires no previous experience. This is simply not true and that is why I feel justified in describing it as the worst language tutorial book I have ever tried to use. Even for the experienced programmer its usefulness is severely dented by the ragged organization and by the terrible index which leaves a considerable part of the book's content inaccessible. Read more ›