Learning Python 4th Edition: First Printing Corrections

Below are book corrections repaired in the first reprint of this book, dated January 2010. They are relevant to only paper copies of the book's first printing (September 2009).

[Oct-28-09] Page xxxvii, missing underscore in __index__
On line 16 of table P-2 on this page, "_index__" should be "__index__", with two leading underscores. This was a bad last-minute insert on my part.
[Nov-11-09] Page 37, "fist line" should be "first line" (minor typo)
In the first line of the second-last paragraph on this page, "fist line" should be "first line", of course. This is in text added for this edition, but the typo wasn't noticed by anybody who read this before publication (including me!).
[Dec-8-09] Page 48, last output line missing in example at top of page
In the second code listing section on page 48, the program output should include a 4th line "Spam!Spam!Spam!Spam!Spam!Spam!Spam!Spam!" after the last line "1267650600228229401496703205376". This was apparently another bad cut-and-paste on my part. The correct, full output of this script is shown in five other places in this chapter (pages 43, 44 (twice), 49, and 51), so most readers should be able to work past this, but its output here may confuse if not patched in reprints. The correct second code listing on this page should look like this -- the last line is what to add:
```
C:\misc> c:\python30\python script1.py
win32
1267650600228229401496703205376
Spam!Spam!Spam!Spam!Spam!Spam!Spam!Spam!
```
[Dec-14-09] Page 59, middle of last line of first paragraph, "C:Python26" missing a "\" (minor typo)
A directory path is missing a first backslash here (perhaps obvious from many other examples in this section, but worth a fix). Change "C:Python26\Lib\idlelib" to "C:\Python26\Lib\idlelib"
[Nov-03-09] Page 81, missing quote in interactive session output, lost in conversion
On line 2 of the very last code listing on this page "Spam'" should be "'Spam'", with the leading quote. This is heavily implied by the other examples in this section, and is in interpreter output not user entered code, but merits a patch. (The quote was present in the 3rd Edition, but was dropped in the files I was given as a starting point for work on the 4th Edition; looks like a format converter gone bad...)
[Oct-28-09] Page 137, sets contain immutables (bad code comment)
In the first code listing on this page, the comment "# Only mutable objects work in a set" should read "# Only immutable objects work in a set". This is implied by both the text immediately preceding this code and the examples shown here, but I transposed "immutable" and "mutable" in the comment. Unlike the clarification for page 135 ahead, this is a genuine typo.
[Nov-10-09] Page 201, Need a space in "Becauselists" (dropped by production in QC2)
Immediately after the "Indexing, Slicing, and Matrixes" header on this page, change "Becauselists" to "Because lists". Oddly, the space was there in the material I sent, and remained in both the copyedit and QC1 quality-control drafts; it was dropped in the QC2 version, long after anyone had time to catch it. Must have been either careless fingers or a formatting tool bug...
[Nov-08-09] Page 216, "anydbm" renamed "dbm" in 3.X (lingering reference)
In the first code listing of the sidebar on this page, change the two "anydbm" to "dbm". Also change the one "anybdm" in the paragraph following this to "dbm (named anydbm in Python 2.X)"; omit word "named" if it does not fit, and make both "dbm" and "anydbm" literal font. This isn't necessarily a bug since the book covers both Python lines; the rest of the book is 3.X with 2.X exceptions noted, though, and we should be the same here. The new "dbm" name is noted on page 670, which is listed under "anydbm" in the index, but this still deserves a fix here.
[Nov-10-09] Page 234, line dropped in partial binary data file example
The last two examples in the first code listing section of page 234 aren't completely correct as shown; their "data[0]" is integer zero, not the first character of 'spam' as intended. I can't reconstruct the cause, but given that this code did work as shown, an additional line "data = data[4:8]" was apparently dropped in a cut-and paste somewhere. To fix, change both occurrences of "data[0]" near the end of this listing to "data[4:8][0]". That is, this listing should look like this:
```
>>> data = open('data.bin', 'rb').read()   # Open binary file: rb=read binary
>>> data                                   # bytes string holds binary data
b'\x00\x00\x00\x07spam\x00\x08'
>>> data[4:8]                              # Act like strings
b'spam'
>>> data[4:8][0]                           # But really are small 8-bit integers
115
>>> bin(data[4:8][0])                      # Python 3.0 bin() function
'0b1110011'
```
Most readers probably won't notice this error, because the example is deliberately incomplete anyhow, and isn't intended to work as shown -- like its excerpt on page 98, (noted in the clarifications list ahead), it assumes the existence of a binary file which isn't created until later in this chapter (on page 237). Still, this example's treatment of binary data is partly incorrect as is. Ironically, this code was adapted from a more complete example in Chapter 36, on pages 931-932, which is coded correctly; see Chapter 36 for more on binary files and data.
[Oct-28-09] Page 425, changeable _state_ information, not scope information
Near the end of paragraph 4 on this page, "changeable scope information" should read "changeable state information". While not technically wrong as is (since this section deals with saving information in an enclosing scope), this was really intended to mention state information, as implied by that term's many other appearances in this section.
[Nov-06-09] Page 429, next "three" sections, not "two" (minor typo)
In the last sentence of the 4th paragraph on this page, "next two sections" should read "next three sections". The third section, on function attributes, was added as something of an afterthought, and this sentence wasn't updated. See also the page 431 clarification later on this webpage; the added third section seems like it could use a bit of elaboration in general.
[Dec-15-09] Page 515, paragraph 1, line 2, extraneous "to" (minor typo)
There's a minor typo here that survived our best intentions: change "both to the total-of-N" to "both the total-of-N".
[Nov-01-09] Page 518, indentation of snippet changed by production
Not a bug unless taken too literally, but on page 518, the second line of code, "print('<{0}>'.format(tester.__name__)) # To method call", was not supposed to be indented four spaces (and was not in the material that I wrote). This is just a line of code snipped out of a larger working script, so it's not an error; still, it looks odd enough to fix -- remove the indentation on this line (only).
[Oct-28-09] Page 537, typo in .pth files section introduced by copyedit
In the first paragraph under list heading ".pth path file directories", the text "; we won’t them cover fully here, but" should read "; we won’t cover them fully here, but". I also did not say this: this is the result of a copyedit change to what was a grammatically valid sentence in the final draft. The original read "These path configuration files are a somewhat advanced installation-related feature which we won’t cover fully here, but...". Doh! (See the page 850 correction ahead for a more complete rant about edit changes.)
[Oct-28-09] Page 713, grammar botched in last minute text insert by production
The wording in the second last paragraph on this page was broken by production when applying an insert I requested at the very end of this project. The text "generator functions (topics or expressions introduced" was supposed to read "generator functions or expressions (topics introduced". In production's defense, the generator expression comment added here at the same time went in correctly.
[Nov-11-09] Page 758, "retubrn" should be "return" (minor typo)
The last line of the last code listing on this page should read "return result", not "retubrn result", of course. This code was tested extensively, so I have no idea where this came from; it's in an early draft, so it may have been happy fingers on my part (that, or sleeping at the keyboard...).
[Dec-14-09] Page 817, change "Mylist" to "MyList" in exercise instructions (minor detail)
In the instructions for both exercise #2 and exercise #3 on this page, replace all "Mylist" with "MyList", and replace all "MylistSub" with "MyListSub". (This refers to the 5 "Mylist" in #2, and the 3 "Mylist" plus 3 "MylistSub" in #3.) This way, the case in these names will match these exercises' solutions in Appendix B. This is a very minor detail -- you can call the classes whatever you like, of course, and the names in the instructions are really just approximate suggestions (you won't lose points for changing case in one letter of a class name). On the other hand, this was a reader report, so the fix is warranted to make the instructions match the solutions completely.
[Nov-12-09] Page 818 and 1126, "Metaclass methods" to "Attribute methods" (old terminology)
On both these pages (exercise and its solution), change the title at the start of question number 4 from "Metaclass methods." to "Attribute methods.". This is a bit of a blast from the past; early on in Python, we used to call proxy (wrapper) objects having a __getattr__ "metaclasses", in deference to their delegation roles. Today, though, "metaclass" has a much different meaning, as described in Chapters 31 and 39 -- it's a way to control the class creation process. This exercise label has been present since the first editions of this book (over a decade ago), but has gone overlooked ever since the new metaclass model came online.
[Nov-12-09] Page 850, "raise E,V" is illegal in 3.0, not deprecated (broken by copyedit)
The book's copyedit process reworded some text in the note box on this page in such a way as to break its technical accuracy. To fix, change the start of the 6th line in this page's note from "deprecated in 3.0." to "deprecated in 2.6.".

Some background for people curious about the publishing process: This note describes the switch from "raise Exc, Args" syntax to "raise Exc(Args)", which is recommended in 2.6 but required in 3.X. Here's how the first part read when I submitted it to O'Reilly: " Python 3.0 no longer supports the raise Exc, Args form that is still available in Python 2.6. In 3.0, use the raise Exc(Args) instance creation call form used in this book instead. The equivalent comma form in 2.6 is legacy syntax for compatibility with the now defunct string-based exceptions model, and is deprecated. It is converted to the 3.0 call form if used. ".

When published, this text was changed by the editing process to the following -- a few tweaks for clarity, and one near the end that changed technical meaning in a subtle and critical way: " Python 3.0 no longer supports the raise Exc, Args form that is still available in Python 2.6. In 3.0, use the raise Exc(Args) instance-creation call form described in this book instead. The equivalent comma form in 2.6 is legacy syntax provided for compatibility with the now defunct string-based exceptions model, and it’s deprecated in 3.0. If used, it is converted to the 3.0 call form. ".

The last part of this implies that the comma syntax works in 3.0, but is converted to the new form. This is wrong. I also did not say this. It is the result of a wording change during copyedit which broke the original meaning after the book was submitted for publication. In this case, the edit seems unnecessary, and even logically unsound, given the rest of the description in this note (it happens; copy editors are not programmers, and vice versa). Since this change wasn't run past me explicitly, it was impossible to catch in the timeframe allowed for copyedit review. Unfortunately, this change did not just break grammar, it broke technical accuracy.

I'm probably more picky than most readers, of course, some of whom may not find this small clause in a big book to be confusing at all. Based on my experiences with other books, though, this is probably not an isolated case. In the prior edition, one third of all errata were introduced by the editing and production processes, and this edition seems to be on a similar clip. These processes fix much too, of course, and their contributions are very much appreciated. But truthfully, it's frustrating when a process whose sole purpose is to improve a book actually breaks portions of it, despite pleadings for edit restraint. I've come to accept that this is a regrettable part of the writing experience. Perfection will always be a pipedream in books like this, but publishers tend to allow for more errors than authors might like, as long as those errors are balanced by net results. Judging from the success of this book over the years, this stance is not necessarily wrong.
[Nov-12-09] Page 971, use "person.py" in shell command, not "getattr.py" (minor typo)
This is a very obscure typo (especially since the file name isn't given either), but to match later commandlines here, at the start of the second code listing on this page, change the first line from "C:\misc> c:\python30\python getattr.py" to "C:\misc> c:\python30\python person.py". This chapter generally assumes you know about files and shell commands already, but this is a bit inconsistent.
[Nov-07-09] Page 1026, section heading is one level too deep
On this page the section header line "Decorator Arguments." was inadvertently coded as a level-4 heading, when it should be level-3 like all the other subheadings on this page. Not critical, but worth a fix.

Newer corrections: see the recent corrections page

Back to this book's main updates page

Books

Code

Blog

Python

Author

Train

Find