![[Home page]](PythonPowered.gif "Home page"){kind=small}
| Books | Code | Blog | Python | Author | Train | Find | ©M.Lutz |
Latest update on this page: February 4, 2008
Please see the main updates page for more details about this page's content, as well as links to web pages containing general book notes, and Python 2.6/3.0 information.
This page lists genuine corrections (a.k.a. errata) for the book -- miswordings, code bugs, typos, and so on. Most of these are minor typos. As of November 2008, there were 50 errata, which comes out to about 1 per every 15 pages on average (at 746 total pages). Of these, 16 errata, roughly one third, were introduced by the production/editing process after I submitted the final draft.
Note that as of the 12/2008 printing, all but one of the errata below have been fixed in books printed on that date or later (the page 277 entry, added on February '09, has yet to be fixed). In the list below, errata already fixed in reprints show the date of the fix in parenthesis, at the start of their descriptions (e.g., (fixed 12/08)). see the bottom right corner of the inside of your second cover page for your printing date (e.g., "[12/08]").
This list is ordered by page number, from lower to higher. Items here:
(fixed 7/08) In the Python 3.0 changes section, this bullet item describes the demise of the `X` backquotes expression, but seems to show this using straight quotes as 'X'. This was changed this way somewhere in the production pipeline, but is a fairly minor issue, given the surrounding text. Backquotes are formatted properly later, on pages 96 and 136.
(fixed 7/08) Also in the Python 3.0 section, a comma in program code was deleted, also somewhere in the production process. The "except name value" should read as "except name, value" as described later in the book (see pages 583, 594, 612, and 614).
(fixed 7/08) The "Python mplements" should be "Python implements", of course. Alas, this was spelled correctly in the final draft I sent to O'Reilly, but was broken somewhere in the production pipeline. It originally had 2 spaces before the word, which accounts for the edit. (I make mistakes too, but I've come to believe that the number of typos in a book is directly proportional to the number of hands that touch it before it is published.)
(fixed 12/08) There is a bogus "km" at the end of the output line on this page that looks like this: "1267650600228229401496703205376km". The "km" shouldn't be there, and I have no idea where it came from; it was not present in the final draft I sent to the publisher, prior to production edits. The correct output is more or less implied by the immediately following code listing which shows the same result without the "km", but this might confuse.
(fixed 7/08) The "...error text omittted..." should be: "...error text omitted...". This is in a harmless comment added for the book, not Python code or output.
(fixed 12/08) The "...doesn't completely help, either because the hardware..." should be "...doesn't completely help either, because the hardware...". This is unfortunately another error introduced by the editing process; in this case, the sentence was changed from valid to grammatically incorrect. The original I submitted was worded this way:
Printing the result to produce the user-friendly display format doesnt completely help either: the hardware related to floating-point math is inherently limited in accuracy
(fixed 12/08) The second code listing on the page should have a "import decimal" line added at the beginning --the whole module has not been imported anywhere above. It should read:
>>> import decimal
>>> decimal.Decimal(1) / decimal.Decimal(7)
Decimal("0.1428571428571428571428571429")
(fixed 12/08) The footnote at the bottom of this page should be deleted altogether. It reflects an arguably horrible change made by an editor. Apparently, the editor reworded the first paragraph of this section slightly to change the segue to the next paragraph, but cut and paste the original wording, in its entirety, into the footnote. Hence the redundancy!
(fixed 7/08) There is a space missing between "of" and "small" in the line: "...mutable sequence ofsmall integers...". This note was text I asked to have inserted late in the production process (during QC1) to address a Python 3.0 change. The space was present in the text I submitted, but in defense of production, this was a last-minute addition.
(fixed 12/08) Minor typo: in the "%G" row, "f" at the end should be "F" (we lost the uppercase in Word somewhere along the way).
(fixed 12/08) On page 161, near the end of Table 8-2, an entry lists D4 = dict.fromvalues(['a', 'b']) as an alternative construction technique. There is no fromvalues dictionary method. This should be dict.fromkeys(['a', 'b']), as shown later on page 170, and as can be surmised by running a dir(dict) call interactively.
(fixed 12/08) A "print" must be added at the start of this line in order to see the None return values shown (None displays as nothing, unless it's run through an explicit print). The current:
>>> d2.get('toast') # A key that is missing
None
should be:
>>> print d2.get('toast') # A key that is missing
None # Must print to see None
(fixed 12/08) In the text: "or a series of assignments like D = [], D['a'] = 0, D['b'] = 0", the first assignment "D = []" should be "D = {}" to initialize a dictionary, not a list.
Also, in the last sentence of this paragraph, "because all the keys are the same", should be "because all the values are the same".
(fixed 7/08) In the interaction listing here, "# This works: can chage mutables inside" should be "# This works: can change mutables inside". This is in a harmless comment inserted for the book, not Python code or output.
(fixed 12/08) The "outout.flush()" here should be "output.flush()", for consistency with the rest of this table. Note that this table is abstract, not actual code, so this is a minor typo.
(fixed 12/08) At the end of the fourth paragraph on this page, "intended the loop four spaces" should be "indented the loop four spaces". This was also correct in the final draft of the book I submitted, but was broken by the production process because of a radical rewording on the part of editors aimed at fixing an unrelated typo.
The original wording in the final draft I submitted was: "Ignoring that, what one would often see in C++ code that the loop began being indented 4 spaces by the first person who worked on it:". This was edited into: "Ignoring that, here's the scenario I often encountered in C++ code. The first person who worked on the code intended the loop four spaces:". This rewording fixes the missing "is" in the original and is perhaps easier to parse, but introduces a typo of its own by missing the technical importance of indentation in this discussion.
(fixed 12/08) Minor typo: "if" should be "of" here (especially in a section about if statements).
(fixed 12/08) Minor typo: "the" should be added here.
(fixed 12/08) Minor typo: "third" should be "fourth" here (this refers to an item in Table 11-1).
(fixed 12/08) Minor typo: at the middle of the clause that starts "(recall that variables...", the "initial counters" should be "initialize counters".
(fixed 7/08) In the very first sentence on this page, the "rwords" should be "words". This was correct in the final draft of the book I submitted, but was broken by the production process as well (all the more frustrating, given that that process is supposed to fix spelling errors, not introduce them after the material leaves the author's hands).
(fixed 7/08) In the text here, "sys.sytdout" should be "sys.stdout". This is a minor typo, and is implied by the correct spelling in the immediately preceding code listing.
(fixed 12/08) Minor typo: the "in the context an iteration tool" here should be "in the context of an iteration tool".
(fixed 12/08) Minor typo: the user inputs in the 2nd last line here should be bold.
The Spanish Inquisition employed the comfy chair, not a comfy couch (of course!); I transposed furniture names here somehow. This is a Monty Python skit reference, not a technical issue, so the typo won't exactly make the Mars rover run into a giant boulder or anything... Still, this merits patching in future printings.
(fixed 12/08) This appears to be version skew; Python 2.4's "open" doscstring is what is shown in the book. It was changed in Python 2.5, where we do need to use "file" to get the output shown. Python 2.6's "open" output is similar to 2.5's, but has an extra sentence. In any case, use "file.__doc__" if you really want to match the output shown in the text in 2.5 and later.
(fixed 7/08) Sentence 2 of paragraph 4 on this page incorrectly states that the * operator, and hence the times function "will work on numbers (performing multiplication), two strings or a string and a number (performing repetition), or any other combination of objects supporting the expected interface". This is incorrect -- * works on two numbers, or a string and a number, but not on two strings. That is, string * string is not a valid operation. In fact, if you pass two strings into the times function, it generates an exception, the point of the next paragraph in the book.
This was also something I DID NOT SAY in the final draft I submitted to the publisher. My version mentions the numbers and string/number cases shown in the code listings, but not the obviously incorrect string/string case -- this third case was added by production. Specifically, the editing/production process broke the meaning here by adding the part "two strings or". This was despite the fact that the editors were not Python programmers, and did not ask about the accuracy of the insertion. Unfortunately, a minor insertion of text like this can have a major impact on meaning in a technical book, and editors are sometimes not as careful as they could be.
(fixed 12/08) In the first code listing on this page, the 4th line is indented incorrectly. The "return action" line should be moved 4 spaces to the right, to be indented the same as the line "def action(X):". That is, the "action" function is returned by the "maker" function. As is, the code's indentation generates a syntax error. This will probably be easy for most readers to spot, especially given the description, and the other similar examples in this area of the book. It appears to have been the product of an unfortunate cut-and-paste from the IDLE GUI during the writing phase.
(fixed 12/08) In the last code listing on this page, the 5th line is indented incorrectly. The "return acts" line should be moved 4 spaces to the right, to be indented the same as the line "for i in range(5):", the same as it is in the first code listing on this page. That is, the "acts" list is returned by the "makeActions" function. As is, the code's indentation generates a syntax error. This will probably be easy for most readers to spot, especially given the description, and the other similar example at the top of this page. Just like the prior errata, it appears to have been the product of an unfortunate cut-and-paste from the IDLE GUI during the writing phase.
(fixed 12/08) There is a typo in this sentence that inverts its meaning: the text "our programs with making multiple copies" should be "our programs without making multiple copies". This is implied by other discussion nearby, but might be confusing.
(fixed 12/08) Minor typo: in this sentence, the ", it also possible" should be ", it is also possible".
This was a change made by editors during production on this book. The original I submitted didn't contain the first clause of this sentence, and began "Is it also possible", which was also wrong (this isn't a question), but in trying to repair the mistake, the editors introduced a brand new one of their own (!).
(fixed 12/08) Minor typo: in this sentence, the "defines is own X" should be "defines its own X".
This was a change made by editors during production on this book. The original I submitted was very different, but grammatically correct. In fact, both this and the prior sentences were shorter in my version:
mod2.py imports the first and uses qualification to access the imported modules attribute: ... And mod1.py imports the second, and fetches attributes in both the first and second files: ...
The good news is that the editors expanded each of the sentences around the code snippets here to make them more descriptive. The bad news is that they introduced this errata in the process.
(fixed 12/08) There is a typo in this sentence that inverts its meaning: the text "with stopping and restarting" should be "without stopping and restarting". This is implied by other discussion on this page, but might be confusing.
(fixed 12/08) Minor typo: this should read "having to go through the module".
(fixed 12/08) At the end of the second line in this paragraph, "2.4" should be "2.5". The absolute/relative imports model is only partially implemented in 2.5, the version this book covers. The import syntax itself is enabled in 2.5, but the new absolute-by-default search order is not until 2.7, unless a "from _future__" is used.
(fixed 7/08) In 2 spots of this section, I transposed the I1/I2 and C2/C3 variable names unintentionally. The typo should be apparent from the surrounding text, but it could also be a bit confusing given the introductory nature of this section. Specifically: in this section's very first sentence, "C2.w" should be "C3.w"; in the last sentence of this section's second paragraph, "C3.w(I1)" should be "C3.w(I2).". The more realistic "bob.giveRaise" example at the end of this section clarifies the intent here. Also see pages 467 and 484 for more complete descriptions of method call mapping.
(fixed 12/08) Minor typo: this should read "which would allow you to store...".
(fixed 12/08) In the answer to quiz question #2 on this page, the text states that the inheritance search for an attribute looks "first in the instance object, then in the class the instance was created from, then in all higher superclasses, progressing from the top to the bottom of the object tree, and from left to right (by default)". The "top to the bottom" part of this is incorrect; the search actually proceeds from "bottom to top" in the tree, as implied by the earlier parts of this sentence.
This was also something I DID NOT SAY in the final draft I submitted to the publisher. In my version, the last part of this sentence correctly says the search is "depth-first and left-to-right (by default)", instead of top-to-bottom, which is clearly wrong. In fact, the correct bottom-to-top order through the search tree is stated explicitly numerous times in this chapter. This was broken by an editor who expanded the wording here, which is especially unfortunate in an answer to a chapter quiz question!
(fixed 12/08) The comment here gives the wrong class name as is. It should read: "# self.data differs, MixedNames.data is the same". This is in a comment, of course, so it's not quite a code bug. The point being illustrated is that the instance and class attributes differ, because they are stored on different objects.
(fixed 12/08) The "top to bottom" here must be "bottom to top", as in the prior errata for page 463.
Alas, this also reflects an inaccurate embellishment added by copy editors. My original final draft version of this reads as "(...) Python searches the namespace tree at and above object, for the first attr it can find.". I don't mind adding "bottom to top" as is implied by the figure caption at the bottom of this page, but the added "top to bottom" is incorrect. In fact, this is the second place where this incorrect description was added; it also happens in the answer to quiz #2 on page 463, as noted in the prior errata on this list. I don't think the editor quite appreciated what top-to-bottom really means, or how specific it is in this context.
(fixed 12/08) In the middle of the first interaction listing on this page, the "4", which is the correct output of the line ">>> X[2]", appears at the very end of this line, rather than on a line all by itself as it should. As is, the "4" output appears at the end of the prior line's comment, incorrectly. This should be apparent given the interaction that follows, but might confuse.
This is apparently a typo we inherited from the 2nd Edition, and was introduced by the production cycle during the development of that edition. On the 2nd Edition, this was correct in the version submitted to the publisher, but was broken by the time that edition was published. The typo was present in the material I was given to work on for the 3rd Edition, and was never spotted.
(fixed 12/08) The output of the 1st line displays as "True" today in Python 2.5, not as "1" (this is legacy from a prior edition's Python). It should be:
>>> 'p' in X True
(fixed 12/08) The user input "str(X), repr(X)" should be in bold font here, as they are elsewhere on this page.
(fixed 7/08) There is a case typo in the commented-out line here. It should read "#print C.m.X", with the uppercase "C". This is in a comment, so it's not a bug, and the code would fail if run even with the case fix. It might be confusing to some human readers, though, given that Python is case-sensitive.
(fixed 12/08) Minor typo: change the ",' to "." here.
(fixed 12/08) Bad table reference: this should say "Table 27-1". This was a last-minute insert added for a 3.0 change, which I have no original record of (and no clue as to where this went bad).
(fixed 12/08) The "Mixing from..." here should be "Mixing finally..." (as is, this confuses exceptions with imports).
(fixed 12/08) This entire 4-line statement block here, from "try:" through "print 'caught'" should be in bold font, because it is both code and user input.
(fixed 12/08) The last line in the code sample has a typo. Instead of: "print 'Got', sys.exc_info(){0], ...", it should say: "print 'Got', sys.exc_info()[0], ...".
(fixed 12/08) This is not an error or code bug, but the indentation in the first code section at the top of this page looks odd. It was munged by production, when the code was shifted to the right; it became too long to avoid line breaks, even though the original was within line-length limits. The code will run as is, but it looks choppy.
Specifically, 2 lines should be adjusted to make this easier to read. The "relief=RAISED)" line should be moved 10 spaces to the right, to line up vertically with "font" on the prior line. The "fill=X)" line should also be moved 7 space to the right, to line up with "win" on the prior line. There are more readable ways to code this, but these changes will help fix the choppiness.
(fixed 12/08) At the top of this page, in the bold font comment, "client-side script" should say "server-side script". A minor typo, because this is a comment about an example that is not described at all, but included just as suggested reading by the final exercise.
In brief, CGI scripts run on a web server, to process form inputs and produce an HTML reply page, normally. They are the most basic way to add interaction to a web site, and larger web frameworks build upon their basic model. Client-side scripts are very different; they typically run in the context of a web browser using protocols like AJAX or applets to add interaction. The term client-side, though, can also refer to any non-web scripts that talk to servers (e.g., email and ftp scripts). To learn more about CGI server-side scripts, and network based scripting in general, see the book Programming Python or other resources.
Back to this book's main updates page