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:
  • by Anonymous Coward on Friday July 06, 2012 @04:02PM (#40568517)

    Huh? I got it?

  • by jeffb (2.718) (1189693) on Friday July 06, 2012 @04:03PM (#40568533)
    ...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 on Friday July 06, 2012 @04:13PM (#40568659)

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

    • by FitForTheSun (2651243) on Friday July 06, 2012 @04:57PM (#40569239)

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

      • by MetalliQaZ (539913) on Friday July 06, 2012 @05:07PM (#40569381)

        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 for scoping -- which I ran into while learning Python; That is to say, if it's immediately apparent to a "beginner" then maybe it is a problem?

          When I delete code at the junction between two scopes, sometimes it's suddenly not clear if the current line of code belongs with the deeper scope or more shallow scope -- Esp. when two lines have become concatenated at the cursor. If I insert a newline, my code editor will place the line automatically with the preceding scope. Without constant diligence one may mistakenly include code in the wrong scope. Thus the use of whitespace for scoping is wasting my time in multiple ways over just this one issue.

          Even BASIC's End If allows for better clarity when maintaining and manipulating code. Eg: In C, Pascal, JavaScript, Perl, BASIC, BASH, Java, etc: The 'end scope' token allows me to quickly correct the indention in this instance without requiring additional thought be given to the surrounding instructions.

          After having chased down many bugs due to the aforementioned whitespace issues I've lost my patience with Python. None of the other languages I use have the issue, so I use them instead. I'm a Function over Form kind of guy who's not impressed by the "look" of the code -- I quickly adapt to existing coding styles of the project I'm on for consistency. If coding style was important to me, I'd use a source code formatting utility. I maintain Python code, but I don't ever start a new project in Python... I just can't justify the known waste of time that will occur over something as trivial as scope delimiting.

          Additionally, here's something else to reflect on: I haven't ever been called a "noob" except by a newb.

          • by oldhack (1037484) on Friday July 06, 2012 @09:43PM (#40572247)

            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 suggested one use a special editor (one that colors tabs and spaces differently). Screw that. The language is being ridiculous.

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

              Three things:
              0) It wasn't a complaint, it was a statement of fact.
              1) "looks" is what "form" means.
              2) determining code block nesting is a function of the parser, true, but giving whitespace meaning is an arbitrary choice designed to affect the FORM of the code written in the language, and would otherwise have no effect on the FUNCTION of the code -- Eg: If Python had used C style braces for scoping it wouldn't affect the function of the code you write -- It would only affect its form.

          • by ax25-ack (2666807) on Saturday July 07, 2012 @12:08AM (#40573125)
            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, Python would be more useful to more people (and waste less time) if the language maintainers (and thus fans), weren't so die hard fanatical over this retarding issue of syntax.

          • by whythefucknot (2668899) on Saturday July 07, 2012 @05:50AM (#40574395)

            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 don't really prefer one approach to indentation/whitespace over the other. They both work fine, I have no trouble switching between them and IMO there are vastly more significant factors in choosing a language, as the grandparent says.

            Everyone's a noob at something.

            • 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 in general. No example is needed, you've illustrated that you know perfectly well what I'm talking about.

              Once in said situation, it can be further exacerbated by pressing Enter/Return which typically indents the text after the cursor in line with the indention used on the prior line. I am not the only one editing this code. Sure, I've made the mistakes sometimes too, but I've also found many bugs that were due to other people incorrectly indenting code after removing a section of it -- It's not just me: If you don't know what I'm talking about at this point, you're just trolling.

              In languages where } or "End If" or "fi" or some close scope token is used, the situation can be rectified quickly. Fix the following run-ons:
              say( "hi" ); } txt = "goodbye";
              vs
              say "hi" txt = "goodbye"
              In Python, the lack of a close block token makes you evaluate the surrounding code to determine which indention should be used, whereas, I can hit the "auto indent" key to fix the situation when using other languages.
              If you accidentally deleted the "close block" token in languages that have them it often results in a syntax error (unclosed block), whereas in Python it often results in a runtime error.

              Everyone's a noob at something.

              No, that's typically a derisive term. To me that's like saying: Everyone's a moron sometimes. It's not true. One can be an inexperienced newbie (newby or newb), without the negative connotations associated with "noob" or "n00b"... Being a slang word its meaning may have changed over the years, but some folk still remember the terms' original meanings...

              • by Anonymous Coward on Saturday July 07, 2012 @12:14PM (#40575949)

                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 in general. No example is needed, you've illustrated that you know perfectly well what I'm talking about.

                GP doesn't seem to have any trouble in emacs, I don't have any trouble in vim when editing Python code. I don't know what you use. I can do the equivalent of the selections you do, or select a block of full lines, or select a rectangle, and by using the appropriate method for the action your problem just does not arise. The rare occasions that I do confuse myself I just use the (unlimited, as far as I can tell) undo/redo buffer to rollback/replay what I did and get myself unconfused in seconds. To me it seems that using a good editor and knowing how to use it appropriately makes all the difference. So I agree with GP that the problem may be with your editor.

        • by DubThree (1963844) on Friday July 06, 2012 @10:11PM (#40572461)
          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 condition2: do something2 else: do something3 # if conditions aren't met sleep until there is work to do sleep interval So the sleep was in the else block causing the program to rip through CPU (fortunately there were 4 on the machine, so it was really only 25%), but the point is that things like this can be hard to see. This is a perfect example of trade-offs, IMO. You either have to deal with the scoping with extra parenthesis or you have to pay more attention to the indentation.
        • by chrismcb (983081) on Saturday July 07, 2012 @02:05AM (#40573655) Homepage

          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 whitespace that way. New or not.

          • by Anonymous Coward on Saturday July 07, 2012 @12:47PM (#40576205)

            The fact that it looks nice is highly relevant, it means the human reader and the compiler see the same thing. That results in fewer errors and less visual noise.

            I always look with amazement at the discussions on tab vs space vs some complicated mixture of both when people program in languages languages that ignore whitespace in the first place. If the block delimiters are so wonderful why make such a fuss about the indentation? Just read the way the compiler reads it and you can't go wrong. Oh, you mean that humans are better at reading indented code? Then why not make a compiler that reads it like a human would? I think that makes a lot of sense, and that is one of the reasons I like Python.

            With Python it's considered a mistake now that they allowed both tabs and spaces for indentation, it should have been just spaces and that has been the recommended practice [python.org] for many years. Perhaps the problem arises from people continuing those stupid wars instead of agreeing with the recommendation, and not from the idea that it's useful if humans and compilers read the code in the same way. If you work in an environment where this is an issue use the -t and -tt options, as the linked style guide recommends.

            If your editor can't show the difference between tabs and spaces, can't easily insert or remove a '#' at the start of a block of lines, can't copy blocks of lines easily and can't change the indentation to what's appropriate for the destination, well, my advise would be to look for a better editor. You may be correct that Python is a pain in combination with an inadequate editor, but there are more powerful editors available. Use them.

      • by Hognoxious (631665) on Friday July 06, 2012 @05:24PM (#40569581) Homepage Journal

        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 Anonymous Coward on Saturday July 07, 2012 @06:00AM (#40574423)

        well FUCK ME

        I have been changing other people's python code and screwing around and I was seriously wondering what the hell was wrong with python.

        Now I feel like bashing my head against the wall until I get over this.

        I have not seen this type of shit since I tried to program in brainfuck.. and in that case.. well, yes, I was asking for it.

        HOW can python continue without program function declarations

        No wonder everyone drops it for Perl

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

        • by Anonymous Coward on Friday July 06, 2012 @10:41PM (#40572685)

          The books got bigger for the same reason we don't all use assembly.

        • by Anonymous Coward on Saturday July 07, 2012 @01:59PM (#40576689)

          Now, noobs ... expect to be spoon-fed an answer

          I disagree. They expect to because that's how they've been trained to do. Because:

          (a) that transfers the responsibility away from them (I didn't know -- how can you hold me responsible for something I don't know!?) which is good for them, and

          (b) they can charge you for every spoonful, so that keeps the large complexes in business which is good for them.

    • by XxtraLarGe (551297) on Friday July 06, 2012 @04:17PM (#40568729) Journal

      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 Anonymous Coward on Friday July 06, 2012 @10:51PM (#40572749)

        I've taken a look at a head first book before. Their books are full of pictures and different forms of information rather than straight text with the idea that people learn in different ways. This is what all my college text books are like although they are usually of higher quality.

        What was the audience for the documents you mention?

        All of my college programming texts have been bigger than what you've mentioned.

    • by Thud457 (234763) on Friday July 06, 2012 @04:27PM (#40568865) Homepage Journal

      "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 Anonymous Coward on Friday July 06, 2012 @05:07PM (#40569383)

      Because the 'Head First' style is to throw in silly visuals-- captioned photos, silly cartoons, etc -- to stimulate cognition. That's the theory, anyways.

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

      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) on Saturday July 07, 2012 @02:12AM (#40573703) Homepage
      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 on Friday July 06, 2012 @04:07PM (#40568593)

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

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

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

  • by bhcompy (1877290) on Friday July 06, 2012 @04:40PM (#40568999)

    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 on Friday July 06, 2012 @04:43PM (#40569039)

    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 that are much better at teaching the basics, and a quick google found this site http://www.freenetpages.co.uk/hp/alan.gauld/ which at first glance seems more traditional in its approach.

    Headfirst spends a great deal of time explaining their 'methodology' of instruction. Unfortunately, their stated approach style is not the same as what is actually presented.

    A few years ago I wanted to brush up on my C, and picked up the C for Dummies by Dan Gookin series. Although rather long-winded, and not overly indepth, I found his style to be quite humorous and relaxing, and think it one of the best examples of bringing a complex subject to a level that is readable, understandable, and frankly, able to hold one's interest for the duration.

  • by cornface (900179) on Friday July 06, 2012 @04:48PM (#40569103)

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

  • by MetalliQaZ (539913) on Friday July 06, 2012 @04:52PM (#40569159)

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

  • by Anonymous Coward on Friday July 06, 2012 @04:57PM (#40569237)
    "Veteran computer programmers — adept with languages such as PHP, Perl, and JavaScript — typically have no trouble learning an additional language" I almost died of laughter after that. Really, if someone said to be fluent with only those languages I would keep he/she away from critical parts of business code in C#, Java and Delphi. If one is exposed to PHP only, it almost guarantees that OOP skills are nonexistent, or bad. (It's true that PHP5 and later has introduced some sanity, but the sheer majority of PHP is still utter crap like WordPress, which is not OOP - nowhere near it, even though they claim to use classes.)
  • by Fosterocalypse (2650263) on Friday July 06, 2012 @05:01PM (#40569313)
    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 because I've dabbled in python and am interested in learning more.
  • by prollifik (1094359) on Friday July 06, 2012 @05:49PM (#40569951)
    I don't need that pretentious macro language, i'm more efficient with my obsolete procedural language, and I'm less ignorant about what really goes on inside the machine the so-called "proprietary" crew try to hide. Each time I install my Linux system on a new computer, I review the code of *all* the new drivers.
  • by oldhack (1037484) on Friday July 06, 2012 @09:24PM (#40572051)

    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.

  • by Anonymous Coward on Friday July 06, 2012 @10:01PM (#40572367)

    "Veteran computer programmers — adept with languages such as PHP, Perl, and JavaScript"
    My apologies, veteran computer programmers code in C, or, if they are lazy, in C++.
    Python is a great prototyping tool, but it should not be confused with a programming language and scripting in it, should not be confused with a computer programming. Programming starts with strong types and learning to clean up your own mess. In python, typing is nothing short of prostitution, and one does not even get to know where the mess is, let alone gets to clean after him/herself.
    So I think it is great python is taught as a programming language in schools - it guarantiees job security for old fars like myself who actually studied Computer Science the old fashioned way - by studying the algorithm complexities first (big-Oh-notation, anyone?), and programming languages - last, because any idiot can pick up a programming language, the trick is how to use it properly.

  • by Anonymous Coward on Friday July 06, 2012 @10:57PM (#40572787)

    I've taken a college class in python and a class in c++. I've looked at far too many books. I got into my algorithms and data structures class and the prof is a guy who sits at his desk and reads (in a thick asian accent) the slides that the book publishers give him along with a lot of "you see?"

    Anyway, I'm in the middle of going through udacity's cs101 class which teaches python 2.7 and how to build a web search engine. I think it's a far better and free alternative to picking up a book or going to a class where you might be stuck with a boring prof who just reads the slides.

  • by pigiron (104729) on Saturday July 07, 2012 @12:10AM (#40573141) Homepage
    that should be taught is Lisp or Scheme. I personally recommend a 1.0 or 1.5 LISP with dynamically typed variables.
  • by Anonymous Coward on Saturday July 07, 2012 @03:43PM (#40577529)

    Head First is one of O'Reilly's few fails. What sort of people actually like the cluttered, busy pages and unbelievable amounts of filler?

  • by Anonymous Coward on Wednesday July 11, 2012 @09:31PM (#40623709)

    There is nothing like getting on the road and feeling the wind in hair and being free. If you ride and enjoy meeting other riders or look for a backseat. Welcome to___bikerwoo.com___online dating site for bikers and those who love them. With tens of thousands biker guys and biker girls, you are bound to find your biker friends to share their riding experiences and passion for motorcycles.

  • by hajjumrahservices (2685985) on Tuesday July 17, 2012 @04:22AM (#40670593)
    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]

The only function of economic forecasting is to make astrology look respectable. -- John Kenneth Galbraith

Working...