Follow Slashdot stories on Twitter


Forgot your password?
Book Reviews

Book Review: Head First Python 72

Michael J. Ross writes "Veteran computer programmers — adept with languages such as PHP, Perl, and JavaScript — typically have no trouble learning an additional language, often just by reading online tutorials and stepping through sample code. But for those new to programming, that approach can prove difficult and frustrating. Yet nowadays there appears to be growing interest among such people for learning how to write programs in Python, especially as it is seeing increasing use by Google and other organizations, and is often chosen as the primary teaching language in schools. For such budding programmers, one possible starting point is the book Head First Python." Read on for the rest of Michael's review.
Head First Python
author Paul Barry
pages 494 pages
publisher O'Reilly Media
rating 6/10
reviewer Michael J. Ross
ISBN 978-1449382674
summary A gentle introduction to the Python programming language.
The book's author Paul Barry, is an experienced programmer and lecturer in computing science. The book was published by O'Reilly Media, on 7 December 2010, under the ISBN 978-1449382674. On the publisher's page, visitors can learn more about the book and its author, see feedback from readers, peruse the discussion forum, and read the errata identified so far (many of which appear to be fixed in the most recent printing). The book's example code is available from Head First Labs. It is packaged into a large Zip archive file, containing directories for all the chapters. Additional resources — such as test data — can be downloaded from a page on the website of the school where the author teaches, The Institute of Technology, Carlow in Ireland. (But don't bother trying to use the site's search functionality to find more information about him, because no search results are returned, as of this writing. Hmm, what is the Goidelic word for "fail?")

The book's material, spanning 494 pages, is organized into 11 chapters, plus a supplementary section for more advanced topics. In the first chapter, "Everyone loves lists," the author briefly explains how to find and install on one's computer Python and its IDLE development environment, if necessary. Oddly, he assumes that if it is already present on a Windows machine, then it will be found in the directory c:\Python31; this is repeated in the second chapter as well. More importantly, he mentions the (command-line) command to start the Python shell, but then immediately begins describing IDLE, without mentioning how to get it running. Most of the chapter explains how Python supports lists and functions, although the coverage of the latter topic is much too brief, considering how critical functions are in any programming language, including Python.

The second chapter shows how to bundle up functions into modules, and make them available to other developers through distribution utilities. This may be an important topic, yet it is inconceivable to me as to why, so early in the book, the author dives into the rather involved details of registering with PyPI and distributing a Python module to the rest of the world, before even introducing such language basics as input/output, files, and objects. (More on that later.)

If the reader perseveres through all the flaws in the first two chapters, then she will likely find that the quality of the narrative gradually improves throughout the rest of the book. An example of this is the third chapter, which addresses basic file access and exception handling. The following chapter, which focuses on data persistence, extends the discussion of how to save in-memory data in files, including the use of the standard library "pickle" for dumping and later loading any type of data. The next few chapters introduce the reader to increasingly complex ways of representing data, in the form of lists (again), dictionaries, and (object-oriented) classes. The discussion is fairly clear, except readers familiar with other object-oriented languages may be confused on page 194, where class attributes are being defined in the constructor only. In fact, the author does not fully explain where attributes can be defined, and what their resultant scope would be.

The seventh chapter roughly marks the halfway point in the book, and also is where the focus shifts from developing Python programs to releasing them to the public. The author begins by incorporating techniques presented earlier in the book, to build a Python-based web app, using the popular Model-View-Controller (MVC) paradigm. The next chapter shows how to port those web apps to mobile devices. Chapter 9 extends these topics, by demonstrating how to query for and accept user data in HTML forms on web pages, and in similar dialogs on Android phones — as well as how to store that data in an SQLite database. The next logical step is to learn how to make Python apps scalable, as well as cloud-based, in this case using the Google App Engine (GAE). Readers are also introduced to Django, for form validation. The final chapter, and the appendix, cover a number of miscellaneous topics, such as how to spreadsheet-type data storage, development IDEs, variable scope, unit testing, and regular expressions.

Most readers should find that the relaxed writing style makes this book approachable, though fairly lengthy. Like most if not all of the other books in the Head First lineup, this one is made more palatable with a sense of humor that is not silly — a welcome improvement to any programming book. The best parts are in the "fireside chats," which are fictional and sometimes pointed conversations, oftentimes between two similar components of Python.

Yet the narrative is far from perfect. Some of the phrasing is ponderous, e.g., "Perform the edits to your code" (page 113); why not just "Edit your code?" A few concepts are used without explanation, e.g., the Python value of "None" (page 80). Some technical slang terms are used quite early in the book, yet with no definitions or explanations for the neophyte — e.g. "app" and "webapp" (both on page xvi). Admittedly, most readers of this book will be programmers or other techies, who feel comfortable with those terms. But the Head First series is intended for people just getting started, and thus all such terms should be explained up front, if only briefly.

There are numerous errata not found in the aforesaid list (on the O'Reilly Media website): "tools to for accepting" (page xviii), "design user-friendly websites" (xxvii; should be "learn Python"), "try and" (14, 84 twice, and 188; should be "try to"), "As your plan to" (37; "you plan" was likely intended), "utilities" (49), "users that" (50; should be "users who"), "argument" (52), "a iterable" (53 and 54), "the the list on screen" (64), "the your latest version" (65), "a argument" (71), "gives you with a chance" (88), "file's contents" (123; incorrect plural possessive), "the facilities pickle" (134; probably should be "the pickle facilities"), "your were" (170), "it's new mode" (185; no apostrophe in "its"), and at this point I ceased recording errata. These flaws, plus the 119 already reported, suggest that the author and O'Reilly copy editors did not perform enough quality control when working on the manuscript.

One glaring problem with the material is the dramatic unevenness in the depths of coverage, from one topic to the next. For instance, even though the book is aimed at readers who already know another programming language (page xxiv), an entire section is devoted to establishing the (obvious) non-scalability of having to use an individual print() statement for every item in a list, and the superiority of instead iterating through the list (page 15). Yet in the same chapter, only a couple pages (29-30) are provided to explain functions, with no discussion of topics important to any programmer, such as whether one can set parameters to default values, or how to pass arguments by reference, if it's even possible. Some of this unevenness is due to the book's goal of presenting technical information in an easily-digestible form; for instance, in Chapter 7, the reader is told how a web server returns a web page, but later faces the minefield of invoking Python's built-in web server on a CGI server.

A second significant problem is the often-illogical ordering of material — both high level and low. Chapter 2 illustrates both cases: The author recommends that the reader release her code to the public (in the form of modules) after presumably having learned only one chapter's worth of material, when such code would undoubtedly be unready for public consumption. At a much lower level, the first "There Are No Dumb Questions" entry in the chapter briefly discusses various editors that could be used for writing Python code. This information should have been presented at the beginning of the first chapter, or even in the introduction — not after the reader has already chosen whatever editor seemed most convenient at the moment, and probably saved at least one file of code. A third variation of this problem, is when the reader is tested on concepts not previously presented — such as the "Who Does What?" section on page 53, which quizzes the reader on half a dozen functions, none of which the reader has presumably even seen before, and some of which are never mentioned again in the book!

In terms of the typography of the print version of the book, I found the font face and size to be problematic, especially on those pages where the text appears to have been printed a bit too lightly — at least in the review copy of the book kindly provided to me by the publisher. For instance, all of the code on page 227 is practically unreadable. Throughout the book, in the snippets of code, the comments are a light gray making them quite difficult to read — probably because these are screenshots of IDLE sessions, in which comments are by default displayed in green, which apparently does not translate well to grayscale illustrations.

Overall, this book appears to have received less oversight and editing than is typical in the Head First series. If you are a veteran programmer searching for a concise treatment of Python, then this book is not optimal for you. Yet if you seek an engaging and highly visual introduction to an elegant programming language, then Head First Python can be a worthwhile place to start your journey.

Michael J. Ross is a freelance web developer and writer.

You can purchase Head First Python from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Book Review: Head First Python

Comments Filter:
  • by Animats ( 122034 ) on Friday July 06, 2012 @04:07PM (#40568591) Homepage

    So the book can't decide whether it's an introduction to programming or a language guide for people who already know how to program.

    Why do all these programming books have to be so fat? The original Algol-60 report was 17 pages. "Pascal - User Manual and Report" was 283 pages. "The C Programming Language" ("K&R") is 274 pages. This thing is over 400 pages. Python isn't a big language.

    I'd like to see more pocket reference books and big plastic cards (like those ones for "Calculus" and "Physics" sold to students) rather than these doorstops.

  • by Anonymous Coward on Friday July 06, 2012 @04:17PM (#40568713)

    For noobs, those pocket references are more like throwing a pile of parts on the ground and telling the guy one by one exactly what each part is and each part does.

    OK, now build a helicopter.

  • by RichMan ( 8097 ) on Friday July 06, 2012 @04:34PM (#40568941)

    Programming is selecting an algorithm to achive a behavior.
    Writing a program is using a particular language to express a defined algorithm.
    Somewhere inbetween the programming and the writing is the selection of the language to use.

    If you only learn one language you are not learning programming.

    I had a liberal prof for computing 101. They said we could write the matrix solving program tasked in any standard language we wanted as long as we stuck to the language basics and not precanned libraries. I selected APL.

  • by i kan reed ( 749298 ) on Friday July 06, 2012 @04:55PM (#40569223) Homepage Journal

    Why can't perl be a programming language? No iron rule I've heard says that programming involves compiled machine code. You can write PROGRAMS with perl. What definition do you use?

  • by luis_a_espinal ( 1810296 ) on Friday July 06, 2012 @04:55PM (#40569227) Homepage

    For noobs, those pocket references are more like throwing a pile of parts on the ground and telling the guy one by one exactly what each part is and each part does.

    OK, now build a helicopter.

    The noobs of old were able to start up with those spartanly small books. Did the noobs of today became dumber? No, not really. But what has happened is that we have lowered the expectations on what people need to do to become proficient. Part of learning programming was in the struggle of deciphering material and making this work. That on itself is a critical part in developing the critical analytical/thinkering process required for successful application of programming (let alone software development/engineering). If you wanted, you had to work for it (and that was the best programming/hacking lesson of them all.)

    Now, noobs (and even graduates working in the wild) expect to be spoon-fed an answer whenever they post "how do open file? please send me codes." Worse still, ask any random noob to debug a program on paper, and they'll go "wut?". Not that I'm elite or anything (far from it), but it was common in my time (not long ago) for students to debug or trace the state changes of (sometimes pretty large) programs on paper. That was one hell of a way to replace the "magic happens here" with concrete cause/effect examples on how instructions change state. You rarely see that anymore (unless you are very lucky to have a good professor or you are in a pretty damn good CS school.)

    Just as not everybody is naturally gifted or apt of fine arts (God knows if I try to draw a chicken, I end up with a pig/octopus hybrid), not everyone is naturally gifted/apt for software development.

    People have talents in different areas, partly due to personality differences, and partly on their educational upbringing. By lowering the expections on what it takes for learning programming, we don't anyone a service. Are we going to do the same with Mathematics, with Fine Arts?

    Books that try too hard to look approachable by being cute, informal, with pictures of dudes looking at you from the cover page with crooked necks won't make up for people's strengths or weaknesses.

  • by hawguy ( 1600213 ) on Friday July 06, 2012 @04:56PM (#40569229)

    Why do all these programming books have to be so fat? The original Algol-60 report was 17 pages. "Pascal - User Manual and Report" was 283 pages. "The C Programming Language" ("K&R") is 274 pages. This thing is over 400 pages. Python isn't a big language.

    One reason is because when someone's shopping for a "Programming for dummies" book, they try to get the best value by buying the biggest book. If Book A is twice as thick as Book B, then it must be twice as good, right?

    Plus, many languages have a rich set of libraries and frameworks that are a large part of the strength of the language, so are also covered in the same book (things like MVC concepts, Android scripting, Django, Google App engine, etc). K&R didn't try to describe the Motif libraries or how to program a GUI application.

    I almost used the example of Google's Go language - it's relatively new and doesn't have nearly as many libraries behind it as a more mature language like Python, yet A Thorough Introduction To The Go Programming Language [] is over 600 pages long. Can I claim that's the exception that proves the rule? (a saying that has never made sense to me).

  • by ceoyoyo ( 59147 ) on Friday July 06, 2012 @05:10PM (#40569411)

    Assembly, Fortran/Cobol/Pascal and C. They said veteran, right?

  • by Anonymous Coward on Friday July 06, 2012 @05:12PM (#40569447)

    The C Programming Language

    by Kernighan and Ritchie. Because of all the books I ever tried to learn a programming language from, this was the most successful in teaching me the language. (That may have as much to do with the C language itself as the writing of the book. Especially since I already knew how to program in a few assembly languages. But the book was well written.)

  • by sqldr ( 838964 ) on Friday July 06, 2012 @06:52PM (#40570699)

    For one, not everyone agrees on what the correct formatting is.

    And this forces them to agree, at least within the bounds of a function. If you don't, you get "unexpected indent error". If you're checking out people's source and checking in stuff with different indentation then you're an idiot. Python fortunately prevents this.

Any sufficiently advanced technology is indistinguishable from a rigged demo.