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

Interrupting Coders Isn’t So Bad

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck …

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 small Lua…

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. The only re…