Python Pocket Reference

Errata for Python Pocket Reference

Submit your own errata for this product.


The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted Date Corrected
Printed, PDF, ePub, Mobi, Safari Books Online
Page 14
Insert at end of last bullet item in page

A minor insert to clarify how commas work in unparenthesized tuples. At the end of the final bullet item on this page (that begins "The syntax (....)"), add this single sentence, with its "comma" in italics: " When a tuple's parentheses are omitted, the comma separating its items acts like a lowest-precedence operator if not otherwise significant. " [Discussion only follows] This is trivial when this is intended or appears standalone, but can lead to odd syntax errors in contexts where the tuple may not have been expected (e.g., in lambda return expressions). It could be argued that the comma is an operator in general, but it's a special case, as it serves this tupling role only in cases where it's not otherwise significant. It's really specific top-level separator syntax that doesn't work in contexts like function argument lists. A new footnote and similar insert in Learning Python 5th Ed addresses this as well. The insert here adds 2 lines, but there seems ample space on the page.

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Aug 16, 2014 
Printed, PDF, ePub, Mobi, Safari Books Online
Page 73
end of 2nd paragraph, new footnote

As an afterthought, I'd like to add a brief mention of nested sequence assignments: a rare and obscure extension, covered in Learning Python 5E (see its page 343). To clarify, ADD a footnote reference to the very end of page 73's 2nd paragraph: """ The last four ... (3.X)").* """ that references the following new footnote text at the bottom of page 73, where there seems to be ample space (if not, please advise; the font of the code in this is unimportant, as we're tight on space--use whatever is most compact): """ * Sequence assignment also allows a nested collection of values to be assigned to a nested sequence of targets: ((a,b),c)=([1,2],3). In Python 2.X only, this pattern may also be used for function header arguments. """

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Mar 18, 2014 
Printed
Page 90
Last paragraph

"... C and C<newline>++ extensions...." Is this the O'Reilly style for breaking "C++"? Will it be found by search in e-books?

Note from the Author or Editor:
Reprints: remove the line break in the middle of this "C++" literal. This one is so short that it shouldn't have a noticeable impact on the surrounding lines, and there are no later literals in this paragraph that may split. Discussion: whether official style or not, line-breaks in the middle of literals is, unfortunately, common in O'Reilly books. I've raised this issue on each of mine, and pointed out the most grievous for manual repair, but some seem to slip through the cracks anyhow. The rationale is that long literals may cause prior/next lines to be too sparse or choppy if not split, and the shifting that results from fixing one may cause other later literals to be split anyhow. In this case, however, the split literal is so short that the effect of removing the line break will be harmless.

Anonymous  Jul 21, 2014 
Printed, PDF, ePub, Mobi, Safari Books Online
Page 92
end of 2nd paragraph

[Not an error, clarification only] The import algorithm on this page is deliberately abstract and sketchy, and fine as is. But gven that we have one line of space on this page, I'd like to add one more bit of detail. To clarify, CHANGE the very end of this paragraph from "order:", to the following, with "__pycache__" in filename/italics font: "order (where step 2 involves details omitted here, including the 3.2 __pycache__ subdirectory described earlier):"

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Mar 01, 2014 
Printed
Page 111
last paragraph

"... __getattri<nspace><newline>bute__() method." Is this the O'Reilly style of "hyphenating" constant-width text?

Note from the Author or Editor:
Reprints: try to remove the line-break in the middle of this literal, but only if doing so does not stretch/empty the surrounding lines too much, or cause similar literal line-breaks later in this paragraph. Discussion: whether official style or not, line-breaks in the middle of literals is, unfortunately, common in O'Reilly books. I've raised this issue on each of mine, and pointed out the most grievous for manual repair, but some seem to slip through the cracks anyhow. The rationale is that long literals may cause prior/next lines to be too sparse or choppy if not split, and the shifting that results from fixing one may cause other later literals to be split anyhow. I'm marking this one for possible repair, but only if it doesn't harm other formatting; in this case, the literal may be too long to avoid the line-break.

Anonymous  Jul 21, 2014 
Printed, PDF, ePub, Mobi, Safari Books Online
Page 116
1st sentence of last paragraph

[Not an error, clarification only] This section uses relative numbers to refer back to the immediately-preceding two cases of new-style inheritance precedence. It works as is, but could be mildy confusing, because there are numbered items nested in these two unnumbered cases. To clarify, CHANGE: "Python runs at most one (for rule 1) or two (for rule 2) tree searches" to: "Python runs at most one (for instances) or two (for classes) tree searches"

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Mar 01, 2014 
Printed, PDF, ePub, Mobi, Safari Books Online
Page 231
1st sentence under

[Not an error, clarification only] This sentence's parenthetical clause tersely describes shared global memory for threads. It's accurate as is given that interpreter internals covers all memory spaces, but could more explicitly allude to shared object memory--a key component of thread communication. To clarify, CHANGE: "(i.e., lexical scopes and interpreter internals)" to: "(i.e., scopes, objects, and system internals)"

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Mar 01, 2014 
Printed, PDF, ePub, Mobi, Safari Books Online
Page 238
Parenthetical comment in 2nd bullet point

"tread lock auto-release" -> "thread ..."

Note from the Author or Editor:
Yes - please fix as noted (minor, especially given that this appears at the end of the book after "thread" is used often, but worth a patch).

Anonymous  Jul 17, 2014