Skip to main content

How To Be Dissappointed in Something You Recommend

I recommend purchasing Expert Python Programming, by Tarek Ziadé. I am extremely disappointed in this book, but I'm recommending it specifically if you already have a good grasp of Python.

You see, I was really looking forward to recommending this book. I had hoped that the many people I know with a good developer head on their shoulders, but had not approached Python with seriousness before, would find this a perfect introduction to sit down with. While I'm really pleased with the writing and structure of the content, I'm afraid this is a book suffering from severe editing oversights. There are subtle mix-ups in terminology in many places and some code samples that are simply and absolutely incorrect.

This is where I made my decision:

>>> from threading import RLock
>>> lock = RLock()
>>> def synchronized(function):
...     def _synchronized(*args, **kwargs):
...         lock.acquire()
...         try:
...             return function(*args, **kwargs)
...         finally:
...             lock.release()
...     return _sychronized
>>> @locker
... def thread_safe():
...     pass

I'm actually not going to point out the actual two mistakes here (I suspect most people that notice will only notice one of them). I want to demonstrate that the problem can be subtle for someone new, but otherwise with a good understanding of software development. This rendered the text applicable to a much smaller readership than it would have otherwise been perfect. I want to repeat how much I really liked the writing, and that I really am recommending it this book. I simply want to express my simultaneous disappointment. I'm really looking forward to posting a glowing review of a second edition of this book.

A closing note...

I sat with this book on myself for the last two weeks trying to decide what to do about my decision on it. Honestly, it was a difficult choice to write about it at all. I am certainly not making any friends at Packt. Make your own decision with this free sample chapter.


Stephen Thorne said…
It took me a little while to spot the second bug with that example. I think I spotted the 'subtle' bug first :).
Anonymous said…
Well, I am soory about this typo.

But this is a Print On Demand book,
so this errata is fixed if you buy it now IIRC.

Errata page:
Anonymous said…
By the way, I am not sure why you think there's another bug, because the finally block is launched before it returns of course..

try this and see when it goes to sleep:

>>> import time
>>> def f():
... try:
... print 'one'
... return 'three'
... finally:
... time.sleep(5)
... print 'two'
>>> f()
Anonymous said…
The two bugs I noticed were both typos (assuming the code snippet posted here is an accurate copy from the book).

Firstly the "locker" vs "synchronised" one which is in the Errata, but also "return _sychronised" vs "return _synchronised" (missing n)
Martin Aspeli said…
I think this post is rather too harsh. The roundabout way in which you present your criticism is especially jarring. You are "extremely disappointed", and yet you are still recommending it? You have noticed two errors in a code snippet, and yet you are not prepared to explain what they are, or offer any remedial advice for anyone who may have read this and been confused?

I've only read half of Tarek's book so far, but I think it fills an important gap. It takes a fresh approach, by focusing on tools and good practice, rather than simply semantics.

I happen to have written a book for the same publisher. I can attest to the fact that writing a book this technical is a very difficult and time-consuming job, and the realities of deadlines and day jobs mean that we can never spend as much time as we'd like on testing and re-reading every single line and example. The editors, of course, are not going to have the same degree of expertise as the author (or you) and so can't catch problems, and even with great technical reviewers, some things will get missed. If you've ever written a 300 page piece of text, you'll know. :)

In fact, the process of editing and formatting a book is made pretty difficult by a whitespace-sensitive language like Python (I had this problem in several places when my book when through editing).

Expert Python Programming is not a perfect book, but I think you should be more careful in how you throw about phrases like "extremely disappointed". All books have errata, especially in a first edition. This book is rather good, and I'd definitely recommend it to people who want to be Python "experts" (though not to beginners, of course).

Unknown said…
I'd say that any programmer who's been around for long enough to pick up this book will have no trouble identifying those two typos, cross them over and write in correct replacements.

Coming from a mathematics background, I can safely say that there are fields where error-ridden material can be detrimental. However, the book Tarek has written does not fall into such a category and I would not base any substantial criticism on typographical errors.

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this. CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer.  One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC? It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro