Forgot your password?
typodupeerror
Book Reviews

Book Review: Head First Python 72

Posted by samzenpus
from the read-all-about-it dept.
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 amazon.com. 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:
  • ...on both the Python and the prey?
  • by Anonymous Coward on Friday July 06, 2012 @04:06PM (#40568563)

    The nice thing about Python is that I can just type in the pseudocode I have been using for decades, and the interpreter just understands it.

    • by Anonymous Coward

      The bad thing is:
      >>> def append(element, list=[]): list.append(element); print(list)
      >>> append(42)
      [42]
      >>> append(42)
      [42, 42]

    • The nice thing about Python is that it enforces formatting. That is a major bonus to noobs.

      • Re: (Score:3, Informative)

        by MetalliQaZ (539913)

        People who bring up the whitespace issue are noobs.

        The nice things about Python are the clean syntax, multiparadigm design, batteries-included library, the PEP system, and the strong community (django, SciPy, etc)

        Really, It's amazing to me that they can combine major features of functional programming, OOP, and scripting into a single language and yet keep it sane.

        • People who bring up the whitespace issue are noobs.

          Blanket statements like this are typically false. Perhaps they're experienced with other languages, and thus see no need to waste time with Python or its whitespace issues?

          For example: I know several languages and have authored a few of my own as well. I'm not gloating, just being clear: I've been coding for over two decades, and Python is a language which I do know. I don't use Python unless it's absolutely required (maintaining existing code). Following is one issue I have with the use of whitespace

          • by oldhack (1037484)

            The essence of nesting with whitespace is to make the code do what it looks, and the issue you noted is that of editor, not the language.

            A minor challenge it presents is for writing parsers due to collapsing multiple consecutive whitespace characters, which can be either TAB or space, into a single token, but that only concerns tool writers.

            Your "function over form" complaint is a nonsense. How the code "looks", determining code block nesting, is a FUNCTION.

            • The essence of nesting with whitespace is to make the code do what it looks, and the issue you noted is that of editor, not the language.

              C style code can achieve the same whitespace nesting ala the Lisp indent style. [wikipedia.org]

              As a scientist I apply the Scientific Method: I say it's an issue with the language. I use several other languages to test my Hypothesis. It appears to be an issue with the language -- I don't have the issue with any other language.

              I don't think I should have to switch editors just to use a language effectively. I have a similar issue with the Whitespace programming language [wikipedia.org] -- Ie: To effectively use the language it's suggest

          • by ax25-ack (2666807)
            If you are a function over form person, you should count braces / if & endif / what ever you like. If you prefer indentation as syntactical sugar "and" prefer making the code consistent and follow some agreed upon rules, Python is for you. For your example, I would suggest proposing a change to the current PEP for indentation.
            • If you are a function over form person, you should count braces / if & endif / what ever you like.

              No need to count them, my code editor does this for me. It generates the matching ending symbols and can even warn me in real time of unclosed blocks...

              If you prefer indentation as syntactical sugar "and" prefer making the code consistent and follow some agreed upon rules, Python is for you. For your example, I would suggest proposing a change to the current PEP for indentation.

              In any other language I can choose to use indention to denote syntax as well. "Making the code consistent" is the job of my code formatter utility, why waste human life on such trivial things? My issue is with wasting human life on trivial things -- Like hunting down bugs that wouldn't otherwise exist except for Python's use of whitespace. No, really, Py

          • I can't figure out from your description what the problem is. What do you mean by the "junction of two scopes"? Are the scopes adjacent or nested? Are you intending two blocks to combine into one, or for a level of nesting to be removed? An example is needed.

            If there is a genuine problem here I suspect it is with your editor. I've been writing C++ and python code in roughly equal measure (for a living) in emacs for about 10 years, and I've never had any problem along the lines you seem to be describing. I d

            • I can't figure out from your description what the problem is. What do you mean by the "junction of two scopes"? Are the scopes adjacent or nested? Are you intending two blocks to combine into one, or for a level of nesting to be removed?

              Yes. Any and all of these. There is no one specific example, it's just an issue that wouldn't otherwise exist if the end scope tokens existed, instead of giving the whitespace syntactic meaning. For an example, place your cursor at the end of any line of text, and press the delete key until the next line is concatenated with the current line. This situation can arise from various block edit movements as well, Eg: Holding down shift, and pressing the up or down arrow to highlight text. Just editing text

        • by DubThree (1963844)
          Let me preface this by saying that I love Python and it is currently my language of choice for doing almost everything (I prefer C for things that need to be really fast). I have an anecdote regarding a whitespace issue. I had an infinite loop that was supposed to sleep after it did the work if there was work to do. The sleep was there, but it was off by one indentation so the program was consuming 100% CPU, think: {some arbitrary code...} while True: if condition: do something elif condi
        • by chrismcb (983081)

          People who bring up the whitespace issue are noobs.

          NO serious program language would FORCE you to use whitespace the way Python does. It is insane.
          The fact that it looks nice, and most people end up doing it that way is irrelevant. The fact that most editors don't show the difference between tabs and spaces, and that you can't easily comment out some code (or reuse it momentarily, somewhere else) makes Python a paint to use.
          Am I a noob? I've only been using Python for about a year. And I constantly bemoan the whitespace idoicy.
          It is moronic to use whi

      • No, it's the fucking shittest bastard bucket of benighted cuntpus ever.

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

        Second, having something invisible that's syntactically significant is just retarded.

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

          • by chrismcb (983081)

            . If you're checking out people's source and checking in stuff with different indentation then you're an idiot. Python fortunately prevents this.

            Actually it doesn't, and that is part of the problem. Python only enforces that the indentation at a given scope is consistent. But it doesn't say that every indentation has to be 2 spaces or 4 spaces or whatever.

            • by sqldr (838964)

              block/function/potato/potahto :-) You have to bare in mind I was trying to talk to a noob :-) It at least makes you notice it!

          • If you're checking out people's source and checking in stuff with different indentation then you're an idiot.

            If you obsess about something as trivial indentation you're a pedantic wanker and probably an aspie to boot.

            An idiot is someone who can't cope with different placing of braces.

            • by sqldr (838964)

              out last night were we?

              At least that means I'm not an idiot. By the way, I think you'll find the whole linux kernel project are "pedantic wankers" in your book. You would get your patches sent back.

            • by sqldr (838964)

              For the record, I code with someone with aspergers in my demo group. I'll ignore the fact you refer to these people as "aspie" because it's not worth it. If it has an effect on his code, it's that it's disorganised and inconsistent, including down to indentation. I think you're mistaking aspergers for OCD.

              PS. If you can't adopt the coding standards of the rest of the group, please don't ever apply to work for my company.

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

    • Re: (Score:1, Insightful)

      by Anonymous Coward

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

        • 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 to be perfectly clear, what you're saying is that the software can't be patented because it can be executed on paper using nothing more than your mind?

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

      It's probably filled with a bunch of useless rambling by the author. Most "For Dummies" books spend about 3 chapters talking about nonsense before they get to the 4th chapter, 20 pages for "Hello world!".

    • by Thud457 (234763)

      "The C Programming Language" ("K&R") is 274 pages.

      That's funny, mine's 228.
      n00b

    • by SirGarlon (845873) on Friday July 06, 2012 @04:27PM (#40568867)

      Why do all these programming books have to be so fat?

      Because this one has pictures!

      Seriously, a key feature of the Head First series is to use lots of pictures, graphics, humor, even games to take the pain out of reading the book.

      I've come to respect that they actually try to teach you something instead of just flinging 200 pages of dry text at you and letting you try to digest that. Making a subject approachable is not the same as "dumbing it down", and a real master can do the former without doing the latter.

      Note: I do not assert that Head First Python does or does not manage the balancing act between making accessible and dumbing down; I only claim that one should dismiss a book on the basis that it has pictures.

    • 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 [amazon.com] 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 rkww (675767)
        The exception proves the rule - 'no blue bicycles' means that, as a general rule, (ie subject to exceptions) bicycles _are_ allowed. Proves in this case meaning demonstrates.
    • by sqldr (838964)

      Indeed. The cookbooks - now they're allowed to be fat, and the o'reilly python cookbook is a great book. Full of tips. If you're just learning the language, the online tutorials are fine.

    • by chrismcb (983081)
      My "The C Programming Language" is just over 200 pages, while my Python: Essential Reference is about 700. Except that most of the language specific stuff is in the first 100 pages or so, while the gazillion libraries included take up the other 600 pages.
  • by Anonymous Coward

    What do you think the best entry level programming book there is that has been writen for a current mainstream language? Why?

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      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 Anonymous Coward on Friday July 06, 2012 @04:11PM (#40568631)

    Here's a link to see the Intro to the book in Safari Books Online. It gives a good feeling for what the book is like:

    http://techbus.safaribooksonline.com/book/programming/python/9781449397524/how-to-use-this-book-intro/xxv

  • 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 chrismcb (983081)

      >

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

      Sure you are... You are just programming in one language. That is like telling someone who only speaks English, that they really aren't studying History (or math, or any other subject)

  • by Anonymous Coward

    "Veteran computer programmers — adept with languages such as PHP, Perl, and JavaScript"

    Okay, no. No! Writing a ton of php, perl, and javascript does NOT make you a veteran computer programmer. It makes you an iffy web developer.

    • Yes, this raised my eyebrow. Probably should have said something like C/C++, Perl, and Java.

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

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

        • Because, clearly, veteran = old.
          • by Zelatrix (18990)
            If you're implying that the modern English usage of veteran is nearer to "experienced" then you're right, but the word originally derives from the Latin vetus, meaning "old". So I think OP's point is fair.
            • I don't know anyone that uses "veteran" to refer simply to being "old." In my experience, it's always used to denote experience. You can have a veteran soldier that's in his 20s. You can have a veteran teacher that's relatively young, too. In some fields, it does tend to denote some amount of age advancement, I agree.

              (I did not know the Latin root, so thanks for that. I will say, though, that while roots are interesting, few people I know communicate with words that mean exactly what their root would i

  • Veteran computer programmers — adept with languages such as PHP, Perl, and JavaScript

    Wouldn't those be veteran scripters, not veteran programmers? Or maybe veteran web developers?

  • by Anonymous Coward

    I picked up this book because work wanted some scripting done, and I'd been wanting to learn Python for a while.
    I've got experience with C, Pascal, Assembler (6502), etc.

    Even with 'moderate' experience, I found the book to be rather crappy in how it decided to introduce programming concepts.
    As someone else noted above, it starts off with functions, then jumps to building modules from those functions... that sure isn't going to deter the non-professional programmer.

    There are a number of tutorials on Youtube

  • If only it had the +2 bonus modifier than Packt books get, it would be the standard slashdot "this books sucks! 8/10" score.

  • But, um, isn't this post something like 5 years late?

  • You give the book a 6/10 which to me is a derogatory score or at least one that tells me not to buy it, but then you put "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. " Is this based on a person who needs to see a lot of pictures instead of reading and the going to the keyboard and working through the material? Also what books would you recommend? (If you have any) and why? I only ask b
  • The best Python book for experienced programmers is Martelli's Python in a Nutshell. It gets you up and going quickly, but still packs plenty detailed reference material.

    Martelli should update the book with Python 3 material - I'll buy me a copy.

  • Hi this is Abdul Manan. I Read your full story book. Really Cool Amazing Stories and Good Moral... Thanks For This Story....
    Hajj Packages [hajjumrahservices.co.uk]

Kleeneness is next to Godelness.

Working...