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
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
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
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.]
- (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
- (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.
colors = filter(lambda x: x != '_', dir(colors))
self.colorname = swing.JComboBox(colors)
colorslist = filter(lambda x: x != '_', dir(colors))
self.colorname = swing.JComboBox(colorslist)
- (typo/bug) Page 238 (added March 2002) -
In the struct binary data module example:
start, stop = stop, start + struct.calcsize('B'*num_bytes)
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
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.
"; as usual, expression results are echoed back to us
at the interactive prompt:"
"; 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.
def dostuff(); # <- this is a syntax error
doLastThing(); # <- this is okay, but not needed
- (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
os.path.walk('..', test_walk, 'show'
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:
os.system('/usr/bin/mail ... < %(tempfile)s' ... )
os.system('/usr/bin/mail ... < %(tempfilename)s' ... )
- (typo/bug) Page 265, in the get_temperature function:
stop = string.index(data,'°v;F',start-1)
stop = string.index(data,'°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"
from tkinter import mainloop
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
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:
string.replace(labelstr, '\r'), '')
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.
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:firstname.lastname@example.org".
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:
def word(self, index):
def word(self, index):
return self.words[index] # properly indented!
- (typo) Page 356, solution #2:
print "Got comment from %(name)s, skipping printing." %
print "Got comment from %(name)s, skipping printing." % \
- (typo) Page 356, solution #3:
# 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