Learning Python 1st Edition: The Errata Page

This is the official place where updates and corrections for the 1st Edition of the book Learning Python are maintained. It's traditional to call this an "errata" page, but we'll also post miscellaneous updates and supplements here as well (some of the items below don't require changes in the text). This page was last updated on 12/03/02.

How this page is organized

The updates below are grouped by printing number, and ordered by page number within printing. There is just one edition of the book, but we fix typos when the book is reprinted. In other words, items listed below for a given printing of the book may not be present in later printings of the book. See the date on the lower right side of the inside cover pages to see which printing you have. Also note that any bugs posted here have been fixed in the source-code examples file.

Where to report new issues

Comments and typo reports are very much appreciated; we want to make this book as typo-free as possible. You can submit reports to O'Reilly, or email them directly to one of the book's co-authors (see the end of this page for current links): Mark Lutz, or David Ascher. Since the authors maintain this page, emailing us directly is probably the most efficient route. [Note to O'Reilly reprints folks: please contact Mark or David when making changes; we may have a few late-breaking tweaks not listed here.]

Recent additions

(Python change) Multiple places, function scope rules:
The scope rules that Python uses to find the value of a referenced variable changed after the book was published. Today, Python automatically searches the local scopes of any and all enclosing function defs, from inner to outer, before checking the global (module) scope. In other words, there is a new layer (perhaps many) between the L and G, in the LGB rule. This often makes it unnecessary to pass in values from an enclosing scope to a lambda or def, by using default arguments. This change impacts the functions chapter most, but also other examples in the text; all examples still run today, but some may be more complex than they need to be today. This will be covered in detail in the 2nd Edition of this book.
(typo) Page 219, 3rd para, 1st sentence, bad wording:
The order of cmp return value interpretations is wrong here. It should read like this: "The cmp built-in returns a negative integer, 0, or a positive integer, depending on whether its first argument is less than, equal to, or greater than the second one." Run a few cmp(X,Y) calls interactively to see for yourself.
(bug) Page 259, code at the top of page:
As is, this code fails the second time through the loop, because the assignment of a file object to variable "tempfile" in the first iteration hides the module of the same name (which is presumably imported elsewhere). Thus, the call tempfile.mktemp() fails. To make this work properly, use a variable name other than "tempfile" for the file object created within the loop. You could also put the "import tempfile" statement at the start of the for loop, but that's marginally more confusing.
(typo) Page 142, source listing, bogus "_":
The "module.___name__" should of course be "module.__name__", with just 2 underscores before and after. It seems that an extra and bogus "_" was inserted somewhere along the way. This bug is also present in the source-code download package, because some examples were cut and paste from the book's postscript at the end of production. That is, they went from source file, to book postscript, to source file, and so inherited any bugs added during production. The example is correct in the original Word doc file for this chapter.
(code bugs) Page 240-241, source listings, bad calls:
Call format problem: either the do_timing function should not use a "*" in its def header, or calls to this function should not enclose the passed functions in an extra set of parenthesis. As is, the example fails because the "*" returns a single item tuple containing the tuple passed (i.e., "funcs" is one level too deep). Also on page 240, the print statement at the end of do_timing appears to be missing a "," after num_times. The comma is in the source code download, so this looks like it was dropped during book production.
(typo/bug) Page 299, Chapter 10: The JPython grapher example has a bug in the source-code download file, that is not present in the book itself (it was fixed between the time the download file was extracted and the final book draft). If you grabbed the source-code file before it was patched, please make the following change to the GUI.__init__ method to make it the same as in the book. Without the fix, the assignment to "colors" hides the global by that name--a phenomenon documented on page 117.
```
change:
    colors = filter(lambda x: x[0] != '_', dir(colors))
    self.colorname = swing.JComboBox(colors)
to:
    colorslist = filter(lambda x: x[0] != '_', dir(colors))
    self.colorname = swing.JComboBox(colorslist)
```

(typo/bug) Page 238 (added March 2002) - In the struct binary data module example:

change:
    start, stop = stop, start + struct.calcsize('B'*num_bytes)
to:
    start, stop = stop, stop + struct.calcsize('B'*num_bytes)

(typo) Page 303 (added March 2002) - The variable "zx" in the example code snippet should be named "zs", because that is how it is referenced in the following text.

Updates for the first printing, dated 4/99

(info) Page 13 and beyond, chapter 1, clarification: Chapter 1 talks about using "your favorite text editor" to create and save module files of Python code. But, as one reader pointed out, if you're brand new to programming, you might not know what this means. On UNIX or Linux, this may mean using something like "vi" or "emacs"; on MS-Windows/DOS, it may mean using Notepad, the DOS "edit" command, WordPad, MS-Word, etc. You can also use the text editors that are part of the PythonWin port for Windows, and the IDLE package described in an appendix (IDLE is portable between platforms). Plus whatever other editor you may find on your machine--nedit, jot, etc.
(info) Page 13 and beyond, chapter 1, clarification: Another thing we seem to have taken for granted is how to start a command-line session under MS-Windows, for running module files and the interactive interpreter. (This may seem trivial to some, but at least one reader has already asked.) To run a Python program in Windows and see its output, you need to first start a "DOS box" to get the "C:\" (or similar) command-line prompt. To start a DOS box, go to your Start menu, and look for and select the "MS-DOS" icon in the Programs submenu (the icon is labeled "Command Prompt"). At the prompt in the DOS box, type "python file.py" to run file.py; you may need to first run a "cd directory" command to go to the directory where "file.py" was created. A few notes: there are other ways to run programs on Windows (e.g., within the PythonWin or IDLE GUIs); for some ports you may also need to run a ".bat" file to configure some settings (see chapter 1); and you can get a similar command-line prompt under UNIX or Linux by starting an "xterm" or "shell" box.
(info) Page 33, end of first paragraph: This may be obvious, is implied by the example, and is described fully in chapter 3, but I'd like to underscore the notion of variable evaluation for people new to programming.
```
change:
    "; as usual, expression results are echoed back to us 
     at the interactive prompt:"
to:
    "; variables are replaced with their values, and expression
     results are echoed back to us:"
```
(info) Page 35, paragraph 3: One reader suggested that "__builtin__" should be changed to "__builtins__" (plural). It should not, but we also use the plural "__builtins__" on page 217, and never explain the distinction. In short, there is a single "__builtin__" predefined module in the system (in the sys.modules table), and every module namespace gets a predefined attribute called "__builtins__" which references the single "__builtin__" module. By changing some of these predefined attributes, you can customize the set of built-in names, and hence limit access to the machine. So, each module has a "__builtins__" which refers to the single "__builtin__", where built-in names live. But you can get to them through "__builtins__" too, since it's just a link back to "__builtin__". Can you see why we didn't want to explain this? ;-)
(figure) Page 60, figure 2-2: There probably should be 4 cells in the dictionary object pointed to by D, not 3 (2 key:value pairs). On the other hand, this is only a rough sketch.
(typo) Page 108, last sentence, last paragraph: change "assigns toast and eggs" to "assigns toast and ham". Those are the formal argument names with defaults in the def header.
(clarification) Page 110: One reader suggests that the first bullet item would be clearer if it read: "In the call, positional arguments must appear before keyword arguments." (TBD)
(typo) Page 148, table 5-1, row 3, column 1: Change "from mod import" to "from mod import *" (add the star).
(font) Page 153, end of comment in example in mid page: In "# self is the instance", the last two letters look like they're in bold font; they shouldn't be.
(info) Page 171, class PizzaRobot at bottom of page: This isn't a bug, and doesn't need to be changed, but there is really no reason for the PizzaRobot class to have an "__init__" constructor method of its own; it works the same if "__init__" is inherited from class Chef directly.
(typo) Page 177, paragraph 2, sentence 2: Change "...in each class that it lists in its header line." to "...for each class that includes Lister in its header line.". This is implied later in the section; the wording was broken during production, but the original version wasn't very clear either. While we're on this page, change the start of sentence 1 in paragraph 1 to read "As seen in the previous section..."
(info) Page 199, footnote: Should also mention that there is a short PDB debugger example at the end of chapter 8 in this book too.

(typo/bug) Page 205, in Python code near end of the "Why You Will Care" sidebar: Change one semicolon to a colon, and delete the other.

change:
   def dostuff();        # <- this is a syntax error
       ...
       doLastThing();    # <- this is okay, but not needed
to:
   def doStuff():
       ...
       doLastThing()

(typo) Page 205, sidebar, last paragraph, first sentence: Change "there's no ned" to "there's no need". Ned may or may not be able to help ;-).
(font) We've found a bunch of places where the "..." continuation prompt (printed by the interactive command-line interpreter) is in bold font. That might make it seem like the "..." is entered by the user. It isn't (as we explain elsewhere), but to avoid confusion, these should all be changed to non-bold. Places we've seen this:
- p. 76 (within 'a...b')
- p. 78 (4 lines)
- p. 88 (1 line)
- p. 89 (8 lines)
- p. 90 (8 lines)
- p. 107 (1 line)
- p. 105 (1 line)
- p. 117 (1 line)
- p. 118 (1 line)
- p. 119 (1 line)
- p. 120 (2 lines)
- p. 121 (1 line)
(info) General remark: during production, all the module file name labels were dropped. In the original draft, a file's code was preceded by a label line of the form "File: xxx.py", which made it more obvious where imported code was coming from when an "import xxx" showed up later. I haven't yet decided if this warrants a change, but there are a few cases where it might help to make the file name more explicit.

This only happens in examples that appear after module files are explained, so the relationship between an import and the location/file of imported code should be obvious to readers. Moreover, examples in the source-code distribution are marked with the name of the file they should be put in, if you're working along.

On the other hand, there are a few places where it may be clearer if the file names were mentioned in the text, especially for readers who open the book randomly to sections after the modules chapter (e.g., p.178 runs a file called "testmixin.py", which imports a "mytools.py", but neither of the preceding code listings are labeled with their file name). To be decided.
(typo) Page 220: Example of ord(c) should show ord('A') value as 65.
(typo) Page 220: Entry for "tuple(seq)" should say "Returns the tuple version...", not "Returns the list version...".
(typo) Page 224, line 3, word 5: "objects" should be "object" ("A callable object ...").

(typo) Page 234

change:
    os.path.walk('..', test_walk, 'show'
to:
    os.path.walk('..', test_walk, 'show')

(typo) Page 236: Fix indentation of last code line on right column in table 8-11 (not indented enough).
(typo) Page 236: Fix indentation of last code line on right column in table 8-12 for example for urlparse (second line is indented too far, third line not enough)

(typo/bug) Page 259, in example at top:

change:
   os.system('/usr/bin/mail ... < %(tempfile)s' ... )
to:
   os.system('/usr/bin/mail ... < %(tempfilename)s' ... )

(typo/bug) Page 265, in the get_temperature function:

change:
   stop = string.index(data,'&degv;F',start-1)
to:
   stop = string.index(data,'&deg;F',start-1)

(typo/bug) Page 276, Chapter 10 CGI example: seems to be missing the initial "#!/usr/bin/python" line which is referenced in the prose on page 279. This example also seems to be missing an initial print statement in the bail() method, for the required "Content-type" header line (see gush() and whimper()).
(typo) Page 281: Delete space between "FormData." and "__init__" in second text paragraph.

(typo/bug) Page 288: "tkinter" should be "Tkinter"

change:
    from tkinter import mainloop
to:
    from Tkinter import mainloop

(typo/bug) Page 290: It looks like we somehow dropped an entire line from the source-code of the Tkinter browser example. Add the following new line, after the current 6th line from the top in the code listing:
```
    self.listbox.bind('<ButtonRelease-1>', self.select)
```
indented the same as the "self.row = self.row + 1" on line 7. This line is referred to on page 292 (and was "reprinted" there), but it somehow was lost on the earlier page in the __init__ constructor.
(typo) Page 292, near start of longest paragraph: Change "self-select" to "self.select".

(typo/bug) Page 293, extra paren in program code near top of page:

change:
    string.replace(labelstr, '\r'), '')
to 
    string.replace(labelstr, '\r', '')

(info) Page 298, Chapter 10: The JPython grapher example relies on the struct module, which is only present in the newest JPython release. (It imports the pickle module, which imports struct). More details and a workaround for older JPython releases will be posted here soon.
(info) Page 325, last column of last row of table B-1: Change the contact point for the maintainer of the Python port on VxWorks, Jeff Stearns, to read "mailto:jeffstearns@home.com". Jeff says the majority of requests for info about Python on VxWorks now come to him by way of this book, but the email address in the book isn't very reliable.

(typo/bug) Page 352, end of solution 4:

change:
      def word(self, index):
return self.words[index]
to:
      def word(self, index):
          return self.words[index]   # properly indented!

(typo) Page 356, solution #2:

change:
      print "Got comment from %(name)s, skipping printing." %
vars(data)
to:
      print "Got comment from %(name)s, skipping printing." % \
            vars(data)

(typo) Page 356, solution #3:

change:
                  # code from existing program, up to
    graphics.fillPolygon(xs, ys, len(xs))
to:  (left aligned!)
# code from existing program, up to graphics.fillPolygon(xs, ys, len(xs))

(typo) Page 365, index: Delete the "sys.path dictionary" entry (it's a list, not a dictionary!), and add its page number (139) to the entry for "sys.path" immediately above.

Back to the Learning Python page
Back to my homepage

Books

Code

Blog

Python

Author

Train

Find