Python Pocket Reference 4th Edition: Updates Page
Below are the current and official lists of corrections and general notes
for this edition of the book:
Only the first of these is true errata (corrections). The second and
third contain clarifications and supplemental information for readers
of this book. The items in the first two lists are intended to be
patched in future reprints.
A reprint was scheduled to occur in mid December 2009, so entries here
dated before that time have likely been repaired in boooks printed after
that time.
Update: A reprint of this book was run in January 2010, but unfortunately,
none of the items posted here or on O'Reilly's own errata site were fixed in
that reprint (in either the paper or ebook forms). I expect that this
will receive more attention from O'Reilly in the next reprint.
Update: Another reprint occurred in August 2010 (stamped with 08/10 in
the initial pages of both paper and ebook forms), but this reprint picked up
only 1/4 to 1/3 of the items listed on this page. It's possible that some items
here didn't make it to O'Reilly's own site before the updates cutoff, and this
page wasn't checked.
Also note that O'Reilly maintains an unmoderated errata list at its web site
which may or may not intersect with my own here, and can contain entries which
may or may not reflect genuine errors. Because I don't generally have time to
keep the two lists in synch, when in doubt, please use my list here.
I receive automatic email about posts at O'Reilly's site, but you may also
send reports to me directly by emailing lutz@rmi.net.
This section lists book errata to be repaired in future reprints.
It is ordered by page number and labeled with reporting date.
[Reprints: be sure to also check for changes in the clarifications
list later on this page.]
Newer posts
- [Jul-8-10] Page 27, "S.istitle(" should be "S.istitle()" (broken by production)
This method is missing a right parenthesis in the methods list on this page. The right
parenthesis was present in the final draft I submitted, but was dropped somewhere during
the production process.
- [Jul-8-10] Page 50, second list item, "set('eggs')" should be "set('spam')"
Change the second list term "aset = set('eggs')" to read "aset = set('spam')",
replacing 'eggs' with 'spam', so it matches the descriptions that follow this.
- [Jul-8-10] Page 118, last paragraph: zip now allows no arguments; bogus "]" in text
Two fixes in the zip description in the last paragraph on this page.
First, delete the bogus "]" character at the end of 'd')] at the start of line 4.
Second, change the entire sentence immediately following this from
"At least one iterable is required, or a TypeError is raised." to read
"At least one iterable is required, or the result is empty."
- [Jul-8-10] Page 148, os.listdir: pass bytes to suppress Unicode filename decode
At the very end of the listdir description (paragraph 1 on this page), if we have space,
add the sentence:
"In 3.X, passed and returns bytes instead of str to suppress Unicode
filename decoding per platform default (also for glob, os.walk)."
This is a crucial point, as it's required to avoid exceptions for any undecodable
filenames in 3.X. If we don't have space to add anything here, this note is
clarification only; it's described in depth in Programming Python 4th Edition.
Older posts
- [Jan-13-09] Page 50, first list item, "empty dictionary" should be "empty set"
In the first list item on this page, under list heading "set()", the indented
text
"An empty dictionary" should be changed to
"An empty set". This is stated clearly in the paragraph immediately
preceding this, so it's a minor typo, but incorrect nonetheless.
(It's not completely clear where this came from, though the fact that it reads
the same as the dictionary coverage on page 42 strongly suggests a cut-and-paste
gone awry, and the author who wrote it in the midst of a 2000-mile cross-country
move is considered to be a "person of interest"...).
- [Nov-14-09] Page 89 minor wording typo in line 2
There's a bogus "as" in this line: change
"with the same as constructor arguments" to
"with the same constructor arguments".
- [Nov-13-09] Page 92 minor wording typo in line 2 of 4th paragraph
There are two typos in one sentence here (yes, yikes!). In this paragraph, change
"list attribute or access then" to
"list attributes or access them".
- [Nov-11-09] Page 110 (and a few more): literal word split over line break
In the second-last paragraph of this page, the literal word "iterator" is
split across a line break badly, as "itera|tor". This occurs in four other
places as well: pages 47 (string literal 'a\0b|\0c'); 120 ("memory|view");
126 ("Base|Exception"); and 145 ("os.envi|ron"). Not a major issue, but all these
terms should appear on a single line and not be split (or should at least be
hyphenated if split, though this isn't ideal for literals). This is a result of
O'Reilly's formatting process and I asked that these all be fixed during production.
Most were, but a handful seem to have slipped through the cracks (alas, deadlines
are the Mother of many an errata...)
- [Nov-28-09] Page 113, print() default end='\n', not 'n' (minor typo)
The call format given by the print() function's list header is missing a backslash.
In the middle of the 4th last line on page 113, change:
"[, end='n']" to
"[, end='\n']".
This is present in the initial draft, so it's my bad. Apparently, the call
format was copied from the Python 3.0 library manual entry for print(),
which contains the same typo. The Python 3.1 library manual added the
required backslash, but this wasn't caught in the book. The book does get
the '\n' default correct in its more complete coverage of print() on page 60.
- [Nov-06-09] Page 165, dbm/shelve "has_key()" becomes "in" in 3.X
Change the second last line on this page from
"found = file.has_key('key')" to
"found = 'key' in file (or has_key() in 2.X only)"
As explained in the earlier sections on mapping operations and dictionaries
(see pages 14, 41, and 43-44),
the 2.X dict.has_key() method is replaced by the "in" membership operator in
3.X (though both work in 2.X). This holds true for the dictionary-like dbm and
shelve file interfaces as well, and this minor mention apparently was overlooked.
This section lists book clarifications, ordered by page number and labeled
with reporting date. These items are intended to be patched or inserted in
future reprints, unless begun with the text "[No fix required]".
Newer posts
- (None so far)
Older posts
- [Oct-31-09] Page 38, list comprehensions: 3.X loop variable scope
This page states that names bound inside a list comprehension are created in the
scope containing the comprehension. True, but as clearly stated ahead on page 40,
3.X changes this to work like generator expressions, such that the loop variables
are not accessible outside list comprehensions either.
To clarify, at the very end of the 2nd paragraph under "List comprehension
expressions", change
"where the comprehension resides." to
"where the comprehension resides in 2.X (but local to the expression
in 3.X).".
- [Nov-06-09] Page 43, adict.fromkeys() usually called on dict itself
This isn't a bug because fromkeys() may be called both on an actual dict instance
({}.fromkeys('abc')) or on the type name dict itself (dict.fromkeys('abc')), but
the latter form is the far more typical usage. To clarify, in the list term
near mid page that reads
"adict.fromkeys(seq [, value])", change "adict" to "dict".
Also, at the end of this list entry's description,
add the following text in parenthesis:
"...set to value (callable on instance or type name).".
- [Oct-28-09] Page 46, infile.read() end-lines: default only
This section states that text mode files translate line-ends to '\n'.
This is true, but only by default in Python 3.X; see the open() call
on page 113 for its "newline" argument that can modify this. To
clarify, under infile.read(), change
"line ends are translated to '\n'." to
"line ends are translated to '\n' by default.".
- [Oct-28-09] Page 47, outfile.write() end-lines: default only
This section states that text mode files translate '\n' to the platform's
line-end separator.
This is true, but only by default in Python 3.X; see the open() call
on page 113 for its "newline" argument that can modify this. To
clarify, under outfile.write(), change
"line-end marker sequence." to
"line-end marker sequence by default.".
- [Nov-06-09] Page 48, additional file attributes
[No fix required]
This page lists 3 common file object data attributes: closed, mode, and name.
It's not intended to be complete, and there are many additional file
attributes, the set of which varies widely between Python 2.X and 3.X.
For the full story, consult Python manuals or run a dir(F) call on any
open file object F.
- [Nov-14-09] Page 64 and 73, add "[decoration]" to def and class syntax formats
The book covers function and class decorators on pages 67 and 74. Because they are
tied to def and class statements syntactically, though, and because it looks like we
have the room, I want to make this more explicit by adding a line that reads
"[decoration]" just before the "def name..." format listing on page 64,
and just before the "class name..." format listing on page 73. In other
words, these two code format layouts on these pages should look like:
The def Statement
[decoration]
def name([arg,... arg=value,... *arg, **arg]):
suite
The class Statement
[decoration]
class name [ ( super [, super]* [, metaclass=M] ) ]:
suite
The two added lines should be fixed-with font, and their "decoration" should be
italics/replaceable. This is all fairly obvious in the decorator descriptions that
follow these, and the syntax formats are not intended to be complete (they also
don't include 3.X keyword-only arguments and function annotations, which are similarly
described a few pages ahead). Still, given that decorators work in both 2.6 and
3.X and are used widely today, it would nice to include them in the syntax formats.
- [Nov-13-09] Page 74, bullet 4, describes instance method default only
Strictly speaking, this bullet describes the instance method model, which is
the normal case for methods in a class (self recieves the instance). Keep in mind,
though, that this is just the default; Python also has static methods (which
receive no instance) and class methods (which receive a class in self).
Moreover, Python 3.X class methods may be called as simple functions through a class
with no instance at all, and need be declared static only if they are called through
an instance. This is not an errata, because the description is correct for the
normal case, and this brief summary isn't intended to be a complete coverage of all
method variants. The built-in functions section covers staticmethod() and
classmethod(), and the book Learning Python presents the full story on
all method types.
To clarify slightly, though, at the end of the 4th bullet on this page, add this:
"The staticmethod() and classmethod() built-ins support additional kinds of
methods, and Python 3.X methods may be treated as simple functions when called
through a class." In this, "staticmethod()" and "classmethod()" are literals
in fixed-width font. If this does not fit, delete the ", etc." at the end of
bullet 2 to free up a line.
- [Oct-28-09] Page 111, 3.X open(), add link to 2.X version
Page 111 begins documenting the 3.X open() call. Although it's implied
by the book's contents, it would nice to note the location of the
corresponding 2.X open() description, given the prevalence of this
call. At the start of the first paragraph under open(...), add
"See also Python 2.X open() on page 123."
- [Nov-06-09] Index, page 192, link to "def" at "functions"
In the index at "functions, 64", add "(see also def statements)".
As is, most function details are indexed under "def", not "functions",
but "functions" is the first place most readers will probably look.
This section lists general book notes and supplements for
readers of this book. It is ordered by and labeled with reporting
date.
1) None so far
Back to this book's main page