Errata

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.

The text says that file.truncate "Truncates file size to, at most, size bytes" implying that the file cannot be lengthened. The docs here:

https://docs.python.org/3/library/io.html?highlight=seek#io.IOBase.truncate

say instead that it will "Resize the stream to the given size in bytes", and testing on Windows with CPython 3.5 shows that it does in fact lengthen files.

Note from the Author or Editor:
[No change required; informational only.] Your point is valid, but this is not a "serious technical mistake," and the text in question does not necessarily imply that the file cannot expand as a result of the call. It may expand to fill size bytes too, and the text does not state otherwise. I agree that this could be embelished, but it is not incorrect, and expansion is an anti-goal of this book. The full story on file.truncate is readily accessible in other resources, including Python's more complete (but more weighty) standard manuals set.

The text says that file.name gives the 'String name of corresponding external file', strongly implying that this will be the file name. The docs here:

https://docs.python.org/3/library/io.html?highlight=seek#io.FileIO.name

say 'This is the file descriptor of the file when no name is given in the constructor', and testing on Windows with CPython 3.5 shows that it does return the file descriptor, not the file name, if a descriptor was passed to 'open'.

Note from the Author or Editor:
[No change required; informational only.] Your point is valid, but this is not a "serious technical mistake." This book is a quick-referencce resource, not an exhaustive listing of every possible option in Python programming--that would require a much larger book. In this case, the text documents the most pervasive semantics for file.name; interpretation for descriptor-based files would naturally differ, and is readily accessible in other resources, including Python's more complete (but more weighty) standard manuals set.

For sets, you describe (among others) the operators: < > <= >= so you may as well describe == and != also. I've tested them on 2.7 and 3.6, and they work.

Note from the Author or Editor:
[No changes required] I understand your point, but your suggestion is unfounded. The "==" and "!=" operators do not appear in any of this book's type-specific operation tables. This is intentional. Instead, these operators are listed in the preceding sections on general operations which apply to and work on all types (e.g., see Table 2 on page 16, and the text before it which notes the application to all types).

Sets call out "<", ">" and the like specially only because their meaning differs from that of all other types; "==" and "!=" do not. You may or may not concur with this organizational choice, but it works, and changing it just for sets would render the book redundant, inconsistent, and non-orthogonal (e.g., "==" and "!=" would have to also appear at lists, strings, dicts, etc.). Though tangential, these operators' class methods __eq__ and __ne__ are also covered in some depth on pages 121-122.

(Aside: I welcome input and hate to pick on an individual post, but this, as well as numerous similar posts you've made against Learning Python 5th Edition, can be fairly classified as uninformed and knee-jerk. Please review a book's content before recommending changes to it here.)