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.

Comments

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: http://atomisator.ziade.org/wiki/Errata
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()
one
two
'three'
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).

Martin
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 operat...

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...

Announcing Feet, a Python Runner

I've been working on a problem that's bugged me for about as long as I've used Python and I want to announce my stab at a solution, finally! I've been working on the problem of "How do i get this little thing I made to my friend so they can try it out?" Python is great. Python is especially a great language to get started in, when you don't know a lot about software development, and probably don't even know a lot about computers in general. Yes, Python has a lot of options for tackling some of these distribution problems for games and apps. Py2EXE was an early option, PyInstaller is very popular now, and PyOxide is an interesting recent entry. These can be great options, but they didn't fit the kind of use case and experience that made sense to me. I'd never really been about to put my finger on it, until earlier this year: Python needs LÖVE . LÖVE, also known as "Love 2D", is a game engine that makes it super easy to build ...