Python Pocket Reference 4th Edition: Updates Page

Below are the current and official lists of general notes and corrections for this edition of the book:

Only the last of these is true errata (corrections). The first and second contain notes, clarifications, and other supplemental information for readers of this book. The items in the last two lists are intended to be patched in future reprints.

O'Reilly also maintains a (partly unmoderated) errata list at its web site which may or may not intersect with my own here, and can contain unconfirmed 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 consult both this page and O'Reilly's. 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.

Reprints News

Book Notes

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)

Book Clarifications

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

  1. [Jan-11-12] Page 179, Python 3.2 removes struct.pack functionality for str
    Per this note at Learning Python's update pages, the struct.pack call described near the end of the book no longer accepts str strings as of 3.2, causing the example near the top of page 179 to fail. To fix, you must manually encode str strings to bytes strings per the note. No book fix is required, as the example works as shown in 3.1.

    Older posts

  1. [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).".

  2. [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).".

  3. [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.".

  4. [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.".

  5. [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.

  6. [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.

  7. [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.

  8. [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."

  9. [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.

Book Corrections

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 earlier on this page; many of its items require reprint edits too.]

    Newer posts

  1. [Feb-1-11] Page 11, first paragraph, typo inherited from Learning Python 4E
    Change the text: "X < Y < Z produces the same result as X < Y and Y < X" to read as: "X < Y < Z produces the same result as X < Y and Y < Z". This text was copied from Learning Python, where it has already been patched and corrected.

  2. [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.

  3. [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.

  4. [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."

  5. [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

  1. [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"...).

  2. [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".

  3. [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".

  4. [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...)

  5. [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.

  6. [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.



[Home page] Books Code Blog Python Author Train Find ©M.Lutz