Errata

The website for fetching code is listed incorrectly as http://oreil.ly/LearningPython

That url is also given on page xlvii as the publisher's site.

It didn't take long to find the correct url and took me to some strange places.

Great book, I'm enjoying and learning a lot so far. And I like the detail and forward references. Roberto

Note from the Author or Editor:
Did you miss the "-5E" at the end of the URL? It appears as the following correct/working URL in both the paper version and ebooks (PDF, Mobi, and Epub versions are all correct as far as I can tell):

http://oreil.ly/LearningPython-5E

If there is another format/viewer where the URL is not appearing correctly, please repost this issue with more details.

In chapter 32, the listing for spam_class.py, class Sub, method printNumInstances has a call to Spam.printNumInstances(); it should be Spam.printNumInstances(cls)

I am reading this on Safari so I don't have an actual page number. Also, the code on github is missing the same argument.

Note from the Author or Editor:
[Not errata, no changes required, informational reply only]

This example spans pages 1067-1069 in the latest printing (and 1031-1033 in older printings). It is correct as coded, run, and described in the book, but I'm retaining this post because it may help other readers understand the subtle nature of the example. First of all, keep in mind that the core idea of class methods is that they are always _automatically_ passed a class object first argument, whether called from instance or class. So, in the example's code:

x = Sub() # Makes an instance of subclass
x.printNumInstances() # Passes x.__class__ (i.e., Sub) to cls of Sub method
Spam.printNumInstances() # In Sub: passes Spam to cls of Spam method

You can see this in the first call's output shown, which traces the value of the cls argument. Notice how cls is first Sub in the subclass's method (line2), but then Spam in the manually-called superclass's method (line 3); both cls arguments were passed in automatically:

>>> x.printNumInstances()
Extra stuff... <class 'spam_class.Sub'>
Number of instances: 2 <class 'spam_class.Spam'>

The Sub.printNumInstances() direct call shown works the same as calling from instance x; Sub's method is invoked with Sub, which invokes Spam's method with Spam. The larger point of this example, though, is that the _lowest_ class of the call's subject is passed to class methods; in the following, Other is passed to the Spam method's cls, because there is no subclass redefinition to catch and reroute the call with a different automatic cls:

>>> z = Other()
>>> z.printNumInstances()
Number of instances: 3 <class 'spam_class.Other'>

That may better capture the utility of class methods--to process per-class data--than the Sub subclass example. For another example that further illustrates the effects of the automatic first argument in class methods, see http://www.learning-python.com/classmethods.py.

I'm impressed with the detailed explanation of how to use the yield statement. But "yield" actually returns a value, not necessarily None, which allows the generator to receive values from its caller as well as send values to it, thus implementing coroutines. A simple demo can be seen at www.panix.com/~wje/x20191120a.py.txt
This is huge, but your book is already huge. Probably not worthwhile mentioning that yield returns a value, right?

Note from the Author or Editor:
[No changes required] No, the value returned to send() by a yield expression is explicitly discussed later in the chapter; did you skip over this? Please see the coverage starting on page 618 for this book's exploration of this topic. There's even a question on this coverage in this errata list; see the page 619 reply.

Different people learn in different ways, of course. But for future reference, I recommend reading a section in its entirety before wandering the web for assistance (or posting unfounded suggestions to this page).

And if you want to roam the web anyhow, see also the two related examples on my books-support website; a simple search there might have turned these up:

https://learning-python.com/gendemo.py
https://learning-python.com/async1.py

For better program portability (and other reasons), any chance you could document the pathlib module? It's an excellent alternative to os.path. (I know your books are already thick enough! [And quite useful, btw.])

Note from the Author or Editor:
[No changes required] Are you sure that you're posting to the right book page? LP5E does not cover system libraries like os.path at all. In fact, that library shows up just 7 times, and only in undocumented self-study code in the exercise solutions appendix. The pathlib module may or may not be a useful alternative to os.path, but it's radically off-topic and out-of-scope for LP5E. This is the domain of applications books like Programming Python.

Just as importantly, this book cannot cater to the personal preferences of every reader. I suggest touring the standard library's docs after you've mastered language basics; there's a lot of good stuff there, but it's a second step, and far too much for a language-focused text like LP5E to cover (especially when it seems to change every other month).

The two string formatting examples in Table 7.1
"a %s parrot" % kind
"a {0} parrot".format(kind)
give an error in Idle
NameError: name 'kind' is not defined

To make examples work a quoted string is needed:
"a %s parrot" % 'kind'
"a {0} parrot".format('kind')

Note from the Author or Editor:
No, this is an abstract code snippet in a table, which uses a variable that's assumed to be assigned in actual use. It's not a complete working example, and there are other snippets like this in the same table. To run, simply assign a "kind" variable of your own.

No changes required, but keeping as a clarification for other readers.

The sentence "This file contains two Python print statements,[...]" is only true for Python 2.x where print is a statement, but for Python 3.x, which the code seems to be for, the sentence should read something like "This file contains two statements which are calls to the Python print function,[...]".
On the following page 29 the first sentence after the image is "I’ll explain the print statement,[...]" for which the same as above applies.

Note from the Author or Editor:
[Not an error, no change required; retaining only as a note for other readers.]

The post's point is well taken (print is a function call in 3.X but a unique statement in 2.X), but the "statement" terminology used here is not incorrect, and was chosen deliberately to apply to both the Python 2.X and 3.X lines without requiring further elaboration so early in the book.

In truth, this code _is_ two statements in both lines. In 2.X, it's two unique print statements. But in 3.X, it's also two statements -- call expressions on lines of their own, which happen to call print. Either way, it's two print statements.

Moreover, this section pretty clearly defers to later sections for finer precision, and the book later documents its use of "statement" for print operations as an intentionally version-neutral description. Clarifying the 2.X/3.X print distinction is too much detail at this early point in the book, and is postponed on purpose.

And if that's not enough to merit a pass, describing these as "calls to the Python print function" would be incorrect for readers using Python 2.X -- this code works as is in 2.X, and the parenthesis don't make these calls in that line (they simply enclose an expression).

Hence, clarifying the 2.X/3.X semantic difference is more trouble than it's worth at this early location, and seems a minor point in any event.

Spelling mistake "save" spelled as "shave" , in page 4 paragraph 3rd second last line.

Note from the Author or Editor:
[No edits required] The use of "shave" here and elsewhere is intentional and correct -- its somewhat informal English meaning is to reduce -- but you are not the first to ask, so I'm retaining this as a clarification for other readers.

Moreover, because the interactive ses-
sion automatically prints the results of expressions you type, you don’t usually need to
say “print” explicitly at this prompt:
>>> lumberjack = 'okay'
>>> lumberjack
'okay'

This suggests, "print" is implied in interactive mode. However the output is actually different if print is literally written in the statement:

>>> lumberjack = 'okay'
>>> lumberjack
'okay'

>>> lumberjack = 'okay'
>>> print (lumberjack)
okay

In the first output there are quotes, in the second there are no quotes.

Note from the Author or Editor:
[Edit]
This is actually just before the first code listing on page 50 in recent printings. At the end of this paragraph, which concludes with:
""
say “print” explicitly at this prompt:
"""
Append text to change this to (keeping the quotes formatting):
"""
say “print” explicitly at this prompt (the format of automatic prints can differ slightly, but you don't yet need to care):
"""
This will overflow the line, bit it looks like there's ample room on this page to avoid changing page breaks; please run this past me after the edit to verify.

[Discussion only follows]
Good point, and you're right that the output of print() and interactive echo isn't 100% identical in some cases (technically, this is the difference between Python's repr and str displays, as covered later in the text). But the point of the narrative at this early location in the book was just that your results are automatically displayed at the interactive prompt, without requiring you to code a formal print().

This differs in files, and it's common for beginners to miss the distinction. The book here does not claim that the output format for echoes and prints is always exactly the same, and explaining the subtle reason why only the former display quotes for strings seems far too much detail on page 49.

That said, it's worth the simple insert above to head off potential confusion over this. It also seems worth retaining this post for any other readers with the same query (with type changed to "clarification;" this isn't a mistake).

For more on the subtle echo/print() formatting difference, be sure to see the sidebar "str and repr Display Formats" on page 149; the coverage of print() in Chapter 12; and the later coverage in the Classes and OOP part of the book for the __repr__ and __str__ methods which implement the two output formats. As a tutorial, this book's best advice almost always is to "read on."

The code sample suggests it is being run from Linux (note the "%" command prompt); yet the output of "sys.platform" is still "win32". For consistency, this should probably be "linux".

Note from the Author or Editor:
[No changes required, not errata, informational note only; this is on page 74 in recent printings]

Thanks for your note; I'm retaining this as a clarification for other readers, but dismissing it as not-an-errata for three reasons: this example's section does not mention Linux at all, and it is not implied; the "%" prompt is very clearly documented as a generic (i.e., platform-neutral) system prompt earlier in this chapter on pages 44 and 48; and this example is run the exact same way--with a "%" prompt and Windows output--on page 56. That doesn't qualify as inconsistent.

Having said that, in retrospect I sometimes regret that more examples were not demonstrated on Linux or Mac OS. In fact, I use Python on Mac OS almost exclusively these days myself, with grudging ports to Windows (see http://learning-python.com/programs.html for recent code). For better or worse, though, Windows was and remains dominant in terms of user base. Luckily, one rarely needs to care about the underlying platform when running the pure-language Python examples in this book.

# B[i] = ord(c) works here too
ord(c) should be ord('c')

Note from the Author or Editor:
CHANGE this comment's text (in line 10 of listing 1) from:
... # B[i] = ord(c) works here too
to this, (replacing just "c" with "x"):
... # B[i] = ord(x) works here too

DISCUSSION: This isn't an errata, and I nearly dismissed it altgether, but opted to retain it with a minor tweak and note, and reclassify as a clarification.

I understand how this may seem confusing, if compared to the "L[1] = 'c' " given for a list above this. However, this is comment, not concrete code, and was meant as abtract only -- it means for some integer "i" and some character "c", "B[i] = ord(c)" works.

Either this should be fully concrete (using 1 and 'c') or fully abstract (using i and c, as given); both would be valid, but changing just the right part to be concrete isn't enough. On the other hand, the "c" is the point of confusion, so we'll change this to use a dfferent variable name to make the abstractness more obvious, and render this moot.

5th Edition, copyright 2013.

In paragraph 5, the fourth sentence is referring to the previous code segment (s[1:3]) when it says, "The second of the preceding operations, for instance, gives us all the characters in string S from offsets 1 through 2 (that is, 1 through 3-1) as a new string". The reader is left thinking that this is the general algorithm for slice interpretation. However, this wording is misleading, and only correct because the first offset in the slice is 1. A more general description would be to say that this expression gives you 2 (3-1) characters, starting at position 1.

The example in the next paragraph (paragraph 6) of S[0:3] emphasizes the point. It shows that S[0:3] returns 'Spa' This time, the first offset is 0, and the result is not "all characters between 0 and 3 (3-0)". That would be 'Spam', which is wrong. Instead, it returns 3 (3-0) characters, starting at position 0. This is 'Spa', and the example correctly shows this result.

Note from the Author or Editor:
[No changes required: informational only]

No, this is correct as given (and it's certainly not a "minor technical mistake": category changed, but post retained for context).

This post lays out an alternative (if arguably convoluted) way to interpret some slice examples' limits, but that doesn't make the existing description invalid. The main point in this section is that the upper bound is non-inclusive--by far the slice's most confusing property to Python newcomers; hence the "- 1".

Frankly, this post is reading too much into one sentence in a larger section in an overview chapter, and picking unwarranted nits. Slicing is described correctly both here, and in more detail later in the book; please reread. That said, if these examples inspire some readers to find their own way to look at slices, they're doing their job.

The code block starting with "S = 'shrubbery' is an example of how text-based data can be changed in place. It does this by creating a list using S, changing that list in place, and then joining the list with '' .join() to create a string again.

However, when the ''.join() is run, and the interpreter prints 'scrubbery', the reader is led to believe that S was somehow changed in place. That is obviously wrong, but why then use ''.join() in the example at all. It seems to be less confusing to enter L again, which shows that the list was changed in place, and that the original string was not somehow involved. .

Note from the Author or Editor:
[No changes required: informational only]

No, this is not obviously (or otherwise) wrong. As it states explicitly, this example is about changing *text-based data* in-place in general, not the Python str type.

The latter is indeed immutable, but "text" is a much more general concept, spanning content read from files, scraped from web pages, and so on. Programmers do need to change such text "in-place" even though it may have been extracted as a str type object, and this section surveys two techniques for doing so. It is correct as given.

I understand the poster's point, and it is valid under one strict interpretation (and I'm retaining this post for anyone else who may be deploying such a strict interpretation). But this was not about str immutability, which is amply illustrated both in this same section and elsewhere in the book. Its was about text-processing techniques. The bytes-type example here should be enough to underscore that this was so.

Should "the binary value 10" be "the decimal value 10"? The ASCII code for newline is decimal 10, which is binary 1010. Or am I misunderstanding your intent? Similarly for the answer to question 6 on page 238 (should "binary 31" be "decimal 31"?). Also for two comments in the code listing on page 1167 (should "binary value 97" be "decimal value 97"?) and to the second line above that code listing.

Note from the Author or Editor:
[On pages 108, 246, and 1208 in printings on or after Sep-2016]
This is a bit grey, but to avoid potential confusion, change the referenced items from the first to the second in each of the following, retaining the spacing before "#":

1) Page 108 - from/to:
# \n is a byte with the binary value 10 in ASCII
# \n is one character coded as decimal value 10

2) Page 246, #6- from/to:
binary 31 (a hex escape \x1f), binary 0
literal value 31 (a hex escape \x1f), literal value 0

3) Page 1208 - from/to:
# 'a' is a byte with binary value 97 in ASCII (and others)
# 'a' is a byte coded as value 97 in ASCII (and others)

4) Page 1208 - from/to:
# Binary value 97 stands for character 'a'
# Code value 97 stands for character 'a' in ASCII

[Discussion only follows]
The use of "binary" here was not meant to mean a base-two value, but a literal in-digital-memory value. I can understand the potential confusion in the first instance, where a "10" value might look like a base-two value, but not in the other two, where the "31" and "97" values can't possibly be misinterpreted as base-two values (they're not zero and one digits, after all). Still, this has the potential to confuse -- especially in the first instance -- so I'm marking it for changes as described.

Perhaps more significantly, the use of "byte" is also not ideal here in retrospect: "character" or "code point" are more appropriate in Python 3.X's Unicode world, though it's not too misleading when referring to ASCII, and is accurate for Python 2.X's byte-based string type. Really, the meaning of a numeric value in a string literal varies subtly between Python 2.X and 3.X (it's an absolute byte-value in the former and a Unicode character's code point in the latter), and syntax and display both vary:

~$ py3
>>> s = 'a\n\xC5\u2606\U00002606'
>>> len(s), s
(5, 'a\nÅ☆☆')
>>> list(s)
['a', '\n', 'Å', '☆', '☆']

~$ py2
>>> s = 'a\n\xC5\u2606\U00002606'
>>> len(s), s
(19, 'a\n\xc5\\u2606\\U00002606')
>>> list(s)
['a', '\n', '\xc5', '\\', 'u', '2', '6', '0', '6', '\\', 'U', '0', '0', '0', '0', '2', '6', '0', '6']

But this is firmed up later in the book (see page 1180/1220 for a random example), and is far too much to try to clarify earlier in reprints.

On FreeBSD and NetBSD using python3.6, the transformation of 'sp\xc4m' to include an umlauted A didn't work. I was able to get it to work by setting environment variable LANG to en_US.UTF-8. On NetBSD (where I have access to more versions of python3), (a) the same applies to python3.4 and python3.5, and (b) it seems to be fixed in python3.7; there it isn't necessary to set LANG. Maybe you don't want to go into all those details in the text, but you might want to say something like: "For best results in some cases, set LANG to en_US.UTF-8."

Note from the Author or Editor:
[No changes required] Good point, and I'm retaining this post as a clarification for other readers having the same issue, but this is too large a topic for us to insert at this location in the book.

A quick check shows the example works as shown and without extra environment settings on Mac OS with Python 3.5; on Android with Python 3.7; and of course on the Windows machine used during book development. In all cases tested:

>>> 'sp\xc4m' # 3.X: normal str strings are Unicode text
'spÄm'

That said, the Unicode defaults story in Python seems to have been in flux since the book was published, and some related Windows code-page settings are covered along the way (e.g., page 779). A more complete description that addresses all platforms and Pythons, though, is regrettably beyond this edition's scope.

Code samples to get matrix list by columns. But instead the code has ''row'.

i.e.
Instead of "col2 = [row[1] for row in M]"
it should be
"col2 = [col[1] for col in M]"
for all code references for 'row'.



I

Note from the Author or Editor:
[No changes required] The use of "row" was intentional here. The list comprehension is really stepping though a list of rows, not a column, and its "row[1]" means the second item in each row along the way. Hence, the collection of these gives the second column in the matrix, as described. If something else was intended in your post, please follow up; else, retaining this as a clarification for other readers. [This is on page 111 in earlier printings.]

On Page 120, extend the end of paragraph 3, which concludes with:
"""
tools like range and map.
"""
to read as follows, adding a new sentence (and retaining the literal font on "range" and "map"):
"""
tools like range and map. By deferring results until needed, these tools can both save memory and minimize delays.
"""

We appear to have room on the page for the insert, and a brief mention of the "why" of iterables seems sorely needed here, even though it's covered in depth later in the book.

I'd like to add two short inserts to clarify unparenthesized tuple syntax. It can lead to fairly nasty syntax errors, in constructs such as lambda bodies. This is addressed elsewhere, but could use a bit of elaboration at the insert locations. The two inserts:

1) Page 122, end of 1st paragraph. Change:
"
(the parentheses enclosing a tuple?s items can usually be omitted, as done here):
"
to the extended:
"
(the parentheses enclosing a tuple?s items can often be omitted, as done here; in contexts where commas don't otherwise matter, the commas are what actually builds a tuple):
"

2) Page 278, end of 3rd paragraph. Change:
"
Many programmers (myself included) also find that parentheses tend to aid script readability by making the tuples more explicit and obvious, but your mileage may vary.
"
to the shortened:
"
Many programmers also find that parentheses tend to aid script readability by making the tuples more explicit and obvious*.
"
where the * references a new footnote at the bottom of this page, with text:
"
*A subtler factor: the comma is a sort of lowest precedence operator, but only in contexts where it's not otherwise significant. In such contexts, it's the comma that builds tuples, not the parenthesis; this makes the latter optional, but can also lead to odd, unexpected syntax errors if parentheses are omitted.
"

If this changes page breaks, please ask me to shorten the wording (I've shortened the existing text to try to avoid breaking the current content across pages).

I believe the comment at the end of one of the lines:
# Order-neutral equality tests (== is False)
should be:
# Order-neutral equality tests (!= is False)

Note from the Author or Editor:
Reprints: in the referenced comment text, please change:
# Order-neutral equality tests (== is False)
to:
# Order-neutral equality ('spam'=='asmp' False)
using straight quotes, and keeping all other text unchanged, including the preceding whitespace used for "#' vertical alignment. I deleted the word "tests" so that this still fits on one line.

Discussion: Not an error and just a comment, but I agree this is a bit terse and worth a minor clarification. The intent here was that running strings through set() makes them compare equal (order neutral), while comparing the strings themselves is False (order matters). This is called out in more detail in the next chapter's fuller coverage of sets, where the same example makes this more obvious, and also compares the finding to sorts (Page 170):

>>> 'spam' == 'asmp', set('spam') == set('asmp'), sorted('spam') == sorted('asmp')
(False, True, True)

Interestingly, the "is" identity test is False for these sets too (they have same value but are different objects), but this operator isn't introduced until the next chapter. Per the post, "!=" is False for the sets as well, but that's just the inverse of what's shown, and wasn't the comment's intent about the underlying strings.

Operator precedence is grouped differently in the official documentation (e.g. https://docs.python.org/3.7/reference/expressions.html#operator-precedence) vs. in Learning Python 5th Edition (LP5E). Mostly this is not consequential for regular math, but the division and remainder operators must be listed on the same level of precedence, as described in the official documentation. As written, LP5E describes a different behavior for expressions like the following:

>>> 127 % 20 // 5
Actual result (Python 3.6.8) equivalent to (127 % 20) // 5:
1
LP5E describes the division as having higher precedence than modulus, resulting in an equivalent to 127 % (20 // 5):
3

Note from the Author or Editor:
UPDATE: as described in the original reply below, the formatting of Table 5-2 didn't reflect operator precedence as formally as it might have. We've improved this in the November 2019 reprint by (1) adding borders around table cells to make row membership (and hence precedence level) clearer; and (2) coalescing a few adjacent but separate rows for better accuracy. See the before and after pictures here:

https://www.learning-python.com/LP5E-Table-5-2-Before.png
https://www.learning-python.com/LP5E-Table-5-2-After.png

You can find much more about this change, including both text and PDF renditions of the reformatted table, at this note:

https://www.learning-python.com/book-queries-lp5e.html#q_8

----original reply follows----

Short story: Table 5-2 generally matches Python's docs, but its formatting of a "row" isn't as obvious as it could be, and full accuracy requires coalescing a few adjacent rows.

Details:
This is regarding Table 5-2, which appears on page 141 in recent reprints. This is not an error -- the book's precedence actually matches that of Python's docs, but the table's original formatting of a "row" may leave a bit to be desired, and its content might be less formal than some readers would like.

As is, rows in Table 5-2 are distinguished by having just a little more whitespace between them than their members. For example, the operators in question all belong to the same Table 5-2 row (which includes "@" in 3.5+, not covered in the book) like this:

x * y
x % y
x / y, x // y

Which are formatted the same as the "+" and "-" row that appear as follows above them (and are hence of lower precedence):

x + y
x – y

The book further states on page 143:

* Operators lower in the table have higher precedence, and so bind more tightly in mixed expressions.
* Operators in the same row in Table 5-2 generally group from left to right when combined (except for exponentiation, which groups right to left, and comparisons, which chain left to right).

Thus, the "127 % 20 // 5" should group as "(127 % 20) // 5" per this definition -- as it does. The real issue seems to be that the notion of row membership in Table 5-2 isn't obvious. I seem to recall that we struggled with this in production and the extra spacing was deemed sufficient, but this may not be so. By comparison, Python Pocket Reference uses commas between row members to associate them marginally better, but this would lose in-row semantics in Learning Python's version, and doesn't seem an adequate fix.

Though not mentioned by the errata post, some other Table 5-2 operators also appear to be in different rows when they shouldn't, and may merit tweaks (e.g., "is" and "<" should be in the same row, as should +x, -x, and ~x). On the other hand, I'm not sure this was always crisp in Python docs, and unparenthesized combinations of such operators seem very unlikely.

In any event, thanks for your report, and we'll update this note after exploring options for improvement.

A minor insert to further clarify how commas work in unparenthesized tuples. At the end of the 5th 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 clause and footnote on pages 122 and 278 address this as well, but I'm also propagating the insert here from Python Pocket Reference 5th Ed. This insert adds 2 lines, but there seems ample space on the page.

The text shows the following:

>>> b * 3, b / 2 # Multiplication (4 * 3), division (4 / 2)
(12, 2.0)

Shouldn't the result be
(12, 2)

This is what I see with Python 2.7.7

Note from the Author or Editor:
No, and this is getting a bit redundant, as the 2.X difference is mentioned before this example and described again on the very next page. But to avoid such understandable confusion -- on Page 142, 1st code listing, line 3, expand the comment test on the right from the first of the following to the second, retaining the "#" vertical alignment:

"# Multiplication (4 * 3), division (4 / 2)"
"# Multiplication (4 * 3), division (4 / 2, 3.X result)"

[Discussion only follows]
I'm marking the edit grudgingly, because it gets tedious to see "3.X" called out everywhere a trivial output differs from 2.X, especially when the difference is explained both earlier and later in the text. In this case, Page 138 (before this example, which is just one among many) states:
"""
The X / Y expression performs true division in 3.X (retaining remainders) and classic division in 2.X (truncating for integers). See “Division: Classic, Floor, and True” on page 146.
"""
And again on the very next page following the example (Page 143, shortly before an entire section on the subject on Pages 146-150), the book says:
"""
Also, notice that all the numbers are integers in the first expression. Because of that, Python 2.X’s / performs integer division and addition and will give a result of 5, whereas Python 3.X’s / performs true division, which always retains fractional remainders and gives the result 5.0 shown.
"""
Hence category was changed from technical mistake to clarification, and this is likely the last edit we'll make of this kind. I appreciate such posts and understand their intent, but examples can't generally be understood in isolation from their surrounding context and narrative.

In your excellent book “Learning Python” (Mark Lutz), you referred to following problem:

(Chapter 5, p 143, numbers in action):
“We met this phenomenon briefly in the prior chapter, and it’s not present in Pythons
2.7, 3.1, and later. The full story behind this odd result has to do with the limitations
of floating-point hardware and its inability to exactly represent some values in a limited
number of bits. Because computer architecture is well beyond this book’s scope,
though, we’ll finesse this by saying that your computer’s floating-point hardware is
doing the best it can, and neither it nor Python is in error here.”

Currently I am using Google Colab (Python version 3.6) and get results like:
A = 3.1
B = 3
C = A – B
(C == 3.1)

Returns ‘False’

C returns: 0.10000000000000009

Could you give more information on you to solve this issue. I am more experienced with eg Matlab, where I would expect to have returns resp. True, and 3.1. Or is this something “normal” for Python?

Thank you much.

Note from the Author or Editor:
[No edits required] This shows up on page 150 in later printings and 146 earlier. It's arguably a minor omission from the book as is - it shows how floating-point comparisons are inaccurate, but doesn't give much detail on a workaround, apart from int(), and a comment that mentions round() and floor() and the like.

It's also too big a topic for this page, but in brief, the most obvious way to equate some operands' precisions is to round them uniformly:

>>> 1.1 + 2.2 == 3.3
False
>>> round(1.1 + 2.2, 1) == round(3.3, 1)
True

The more-exotic numeric types described later in this chapter can help too, though they may be more work:

>>> from decimal import Decimal
>>> Decimal('1.1') + Decimal('2.2') == Decimal('3.3')
True
>>> from fractions import Fraction
>>> Fraction(11, 10) + Fraction(22, 10) == Fraction(33, 10)
True

After the book was published, Python 3.5 also added a math.isclose() for this purpose, though it emulates '==' only (e.g., add an 'or x > y' for 'x >= y'):

>>> import math
>>> math.isclose(1.1 + 2.2, 3.3)
True

This new call is also a bit convoluted in some uses cases; see the docs:

https://docs.python.org/3.8/library/math.html#math.isclose

There's no room to change the book for all this, but we'll keep this post as information for other readers.

The paragraph talks about monetary applications and representing cents with two decimal digits. The example suggests that such "cents" in a monetary application will be handled properly if you set getcontext().prec to 2. But the Decimal "prec" (at least with an otherwise default context) is the number of total digits of precision in operations, not in the creation of a Decimal (which stores everything you feed it--see link below). So in the example, Decimal(str(1999 + 1.33)) creates a Decimal('2000.33'). But that actually has 6 digits of precision. Decimal('1999') + Decimal('1.33') in that same context actually yields Decimal('2.0E+3'), not Decimal('2000.33') as the example implies.

I assume there is a way to handle monetary applications (i.e. with a fixed number of "places" after the decimal point) with Decimals, but I don't know it (I am just learning Python ... that's why I'm reading the book). But it can't be by using getcontext().prec = 2 with an otherwise default context (I am using Python 3.3.2 on Win32, FWIW), as in the example.

See https://docs.python.org/3/library/decimal.html#decimal.FloatOperation
"The significance of a new Decimal is determined solely by the number of digits input. Context precision and rounding only come into play during arithmetic operations."

Note from the Author or Editor:
This post seems to expect too much of the deliberately limited Decimal coverage here (see below). To avoid similar confusion, though, let's change the potentially misleading paragraph in question from the first of the following to the second:

"This is especially useful for monetary applications, where cents are represented as two decimal digits. Decimals are essentially an alternative to manual rounding and string formatting in this context:"

"Technically, significance is determined by digits input, and precision is applied on math operations. Although more subtle than we can explore in this brief overview, this property can make decimals useful as the basis for some monetary applications, and may sometimes serve as an alternative to manual rounding and string formatting:"

[Discussion only follows]
All true, and thanks for the informative post which others may find helpful. But you seem to be reading too much into the book's very limited and even terse coverage of Decimals. This is a 2-page tutorial in a chapter on number basics, about a complex tool that has a limited audience, and changes often across Python releases. Its code samples are not the whole story, and weren't meant to be.

The book is at best an introduction to this obscure topic -- as it is for Fractions in the same section, complex numbers earlier in the chapter, and namedtuples in later chapters. Its examples do work as shown: the code in question relies on the 2-digit str() result to set initial sizes, but the "prec" setting would also be applied on future math operations. Still, Decimal is much more complex than presented in the book. The book expects readers interested in the subject to go the docs for more usage details, which you clearly have.

Or, to quote from this brief section's conclusion in the book:
"""
Because use of the decimal type is still relatively rare in practice, I’ll defer to Python’s standard library manuals and interactive help for more details.
"""
Given that, I'm disinclined to write much more about them either in the book or here, when the standard manual fills in their background and details well. Hence, no book changes required apart from the minor rewording above, but post retained for other readers, and category changed from "serious technical mistake" to "clarification", as the text seems to have worked exactly as designed on this.

That said, and viewing this post as a request for clarification, the Decimal class can form the _basis_ of monetary calculations, but it takes more to flesh out a full implementation. For pointers, try a web search for Python Money classes (that yields the following), and see the FAQ on the quantize() method in Decimal's standard library manual (the last of the following):
https://code.google.com/p/python-money/
https://pypi.python.org/pypi/py-moneyed
https://docs.python.org/3/library/decimal.html

Python isn't COBOL, and floating-point and integer suffice as monetary data for many; but fixed point solutions are also readily available. Decimal itself is complex and nonintuitive, is largely skipped in the text, and requires additional research on the part of readers.

In the line
>>> for item in set('abc'): print(item * 3)
the round brackets after the print statement should be deleted
because the section is headed "Set basics in Python 2.6 and earlier".

Note from the Author or Editor:
[Not an error, no fix required, type changed to clarification]

I'm going to dismiss this, but keep it as a clarification for other readers. Because the code in question works correctly in Python 2.X, this seems a stylistic preference. As described later in the book, a "print(X)" works the same as a "print X" on Python 2.X, and even provides a portability path to 3.X -- the extraneous parentheses are simply ignored in 2.X as enclosing a one-item expression, and are not printed. The parentheses would be printed for zero or multiple items, as they are then taken to form a tuple -- requiring other techniques outlined in the book. See page 367 in particular for "print(X)" examples in 2.X. In hindsight, this might have been footnoted earlier in the text, but there's no space for an insert.

Beginning on page 169 and continuing through page 173 sets are described as being immutable.

However, from the language reference (3.7.9) https://docs.python.org/3.7/library/stdtypes.html#set-types-set-frozenset

under set types-

"There are currently two built-in set types, set and frozenset. The set type is mutable — the contents can be changed using methods like add() and remove(). Since it is mutable, it has no hash value and cannot be used as either a dictionary key or as an element of another set. The frozenset type is immutable and hashable — its contents cannot be altered after it is created; it can therefore be used as a dictionary key or as an element of another set."

This seems to contradict what you have written. Can you help me understand? I am new to this so if I have been inappropriate, I do apologize

Thank you
Terry Kummell

Note from the Author or Editor:
[No changes required, retained as a note] Thanks for your input, but no: the book does not describe sets as immutable anywhere. Instead, it correctly states that sets' _items_ must be immutable, even though sets are mutable.

This distinction may seem subtle, but it's a core requirement of the set type.
You can change the set itself in place with methods like ".add()" and operators like "|=" (hence sets are not immutable). But you can store only unchangeable items within the set (hence the items nested within the set are immutable).

This follows from the fact that set items, like dictionary keys, must be hashable: an object whose value may change cannot generally produce a unique and unchanging hash value. Thus, you can store immutable numbers, strings, and tuples in a set -- but not mutable lists:

>>> x = set()
>>> x |= set([123, 'spam', (1.0, 2.0)])
>>> x
{(1.0, 2.0), 123, 'spam'}
>>> x |= set([[4, 5, 6]])
TypeError: unhashable type: 'list'

So, sets themselves are mutable, but their items are not. This is essentially the inverse of tuples -- tuples themselves are immutable, but the items nested within them need not be. That is, sets are mutable collections of immutable objects, and tuples are immutable collections of immutable or mutable objects (tongue twister but true):

>>> t = (1, 'spam', [4, 5, 6])
>>> t[2][0] = 99
>>> t
(1, 'spam', [99, 5, 6])
>>> t[2] ==99
False

The set's constraint on nested items is fairly clear in the book's opening definition: "...the set—an unordered collection of unique and immutable objects...". This is also covered with examples on page 173, where the book is careful to call out the "frozenset" immutable variant type too. Sets are also listed as mutable on page 244, and 277 restates that "set items [edit: not sets!] are unordered, unique, and immutable".

I understand the confusion, but please reread the book's sections on sets with this in mind, and follow up if needed; as described by both the book and Python's docs, immutability applies to sets' items, not sets.

Figure 6.1 and its caption use the word "names" in several places. It would be clearer, and more consistent, if you instead used "variables".

Note from the Author or Editor:
The equivalence is already mentioned once on the prior page (see below); but to further clarify, let's apply two edit in reprints.

1) On Page 176, start of paragraph 2, change the first of the following to the second, with its "name" in italics for emphasis:
"A variable (i.e., name), like a,"
"A variable (also known in Python as a name), like a, ..."

2) On Page 177, start of caption to Figure 6-1, change the first of the following to the second:
"Figure 6-1. Names and objects ..."
"Figure 6-1. Names (a.k.a. variables) and objects ..."

[Discussion only follows]
I agree with the poster in principle, but the book points out the equivalence of "variable" and "name" on Page 176, just before the caption mentioned. It reads like this (with an "i.e." for "that is"):
"""
Variable creation
A variable (i.e., name), like a, is created when your code...
"""
Still, that's a bit terse, and the edits above may help make this more obvious and avoid confusion. Using one or the other terms universally isn't an option at this point, given their widespread usage.

The occasional "name" also highlights distinctions with other languages, and you'll generally see "name" in error messages from Python itself, despite the common use of "variable" in math. Using both terms is intended to have wider scope. In any event, "variables" would be the worse of the two to use -- it's "name" almost everywhere in Python.

the last line of code should not contain a SPACE between "a" and "m".

It should be like:
">>> print(s)
s p
am"

NOT the one on the book:
>>> print(s)
s p
a m

Note from the Author or Editor:
[No edits required] No, the example in the book is correct as shown, but its output may vary across platforms and tools. This code is printing the string:

>>> S = "s\tp\na\x00m"

which contains an embedded tab (\t) after the 's,' and a null character (\x00) after the 'a.' Per Unix convention, a tab counts for as many blank spaces as required to move the output column to the next multiple of 8, which is why the 'p' is spaced further to the right than the 'm' in the book.

The null character's effect, however, seems more open to interpretation: it renders one blank space on Windows Command Prompt, but as nothing in macOS Terminal. Since this example was run on Windows for the book, it's output reflects that platform's results:

>>> print(S)
s p
a m

On macOS and possibly others, the last line is indeed just "am" as you noted, but that wasn't the book's code host (as noted in its Preface), and this is apt to vary arbitrarily. So, what your seeing may differ form the book slightly, but this seems a minor interoperability issue that may be better ignored than covered so early in the text. We will, however, keep this note for the next reader who may be tripped up by this.

(This is on page 206 in earlier printings). A reader wrote by email to ask about the use of "binary" in this clause. Since this is a common confusion (and was addressed elsewhere in the book by previous errata), let's change this clause from:
this returns the actual binary value used to represent
to:
this returns the actual numeric value used to represent

Discussion: this isn't an error in the book, but readers seem to frequently confuse in-memory storage with human-readable display. The use of "binary" at some places in the book refers to the former, not the latter. To help clarify the important distinction, I've posted a fuller look at the issue at this page:

https://www.learning-python.com/book-queries-lp5e.html#q_2

The edit above should minimize some confusion, but I hope the post goes further to clear up some common misunderstandings of the fundamentals to which the text was referring.

Minor nit, but it would be useful to add a back-reference to where this topic was first noted. In line 2 of this note, just before the emdash designated with a double dash here, change: "and a list) work--the"
to: "and a list) work as first noted in Chapter 5--the".

A reader sent this by direct email. Two readers have now logged confusion on this; while it's correct as is, it's worth a minor rewording to avoid further issues.

In the table's entry for Operation
D[key] = 42
change the Interpretation text in column 2 from:
Adding/changing keys
to:
Adding keys, changing key values

[Discussion] The original is correct, because this syntax is used both to insert new keys, and to change key's values (in the same way that a _variable_ is said to be changed by assigning it a new value--keys and variables are both assignment targets). I suspect some readers are reading this differently, though, assuming that keys can somehow themselves be changed in-place; really, we may add and remove keys, but only change them by making them reference new values. A minor shade of difference to be sure, but it's important to avoid confusion early in the book.

The text (penultimate line) says "Technically, this ['in' for dictionaries] works because dictionaries define iterators that step through their keys lists automatically."

I was very surprised by this assertion and seriously doubted that it is true: because dictionaries are implemented as hashes, the operation of deciding whether or not a key is in the dictionary will be very fast by using the hashing algorithm, and should not be done via creating a list/iterable of the keys and linearly searching through it. And checking the Python 3.4 source code, I find that this is indeed the way it is implemented - the 'in' operation for dictionaries is special-cased in exactly this way. See Objects/dictobject.c, around line 2615:

/* Hack to implement "key in dict" */
static PySequenceMethods dict_as_sequence = {
0, /* sq_length */
0, /* sq_concat */
0, /* sq_repeat */
0, /* sq_item */
0, /* sq_slice */
0, /* sq_ass_item */
0, /* sq_ass_slice */
PyDict_Contains, /* sq_contains */
0, /* sq_inplace_concat */
0, /* sq_inplace_repeat */
};

and PyDict_Contains just checks whether the key hash is found in the dictionary without attempting to list all the keys.

A better replacement for this sentence would therefore be: "Although the 'in' membership test for iterables works by iterating through the iterms, dictionaries are treated as a special case because their keys can be looked up very quickly." Or maybe: "The 'in' membership test for dictionary keys is implemented using the fast key lookup algorithm, so it is very efficient." Or something like that.

Note from the Author or Editor:
This may be splitting hairs a bit (as explained below), but to avoid future confusion, let's change this sentence from:

"Technically, this works because dictionaries define iterators that step through their keys lists automatically."

to this:

"Technically, this works because dictionaries define keys iterators, and use fast direct lookups whenever possible."

[Discussion only follows]
I'm marking this as clarification, not errata. Your analysis is technically correct (and kudos on both your exploration and explanation), but the sentence in question was not meant to be rigorous, and was not intended to imply a specific implementation mechanism. Instead, this is a generic and intentionally simplistic statement at an early point in the book when most readers are probably not ready to grapple with subtle shades of difference between general __iter__ and specialized __contains__ methods.

Dictionaries' internal implementation by hash tables is stated elsewhere in this book (see Page 251's paragraph on the subject), and the __contains__ (i.e., "in" operator) customization for dictionaries is mentioned both in a footnote on Page 482, and in the full section on the subject on Pages 906-909. The text straddling Pages 906/907 especially seems to call this out, once OOP has become fair game in the book:

"""
In the iterations domain, classes can implement the in membership operator as an iteration, using either the __iter__ or __getitem__ methods. To support more specific membership, though, classes may code a __contains__ method ? when present, this method is preferred over __iter__, which is preferred over __getitem__. The __contains__ method should define membership as applying to keys for a mapping (and can use quick lookups), and as a search for sequences.
"""

The C code you referenced is the internal equivalent of these class methods. That said, a minor edit here may help disambiguate. I'd also note that discovering this by exploring Python's implementation itself is a great way to clarify such things in open source projects.

In response to a post in a reader forum, I'm going to add some parenthetical text for clarity. Change the end of this paragraph from:

"plays the role of top-level container in realistic programs:"

to:

"plays the role of top-level container in realistic programs (the following snippets both print Bob's 2-item job list if run live and provided with another record structure):"

For the rationale behind this, see the original post and reply at my reader FAQ page, https://www.learning-python.com/book-queries-lp5e.html#q3.

End of paragraph reads:
"(it reads almost the same in Python, but with a bit more formality):"

After the word "Python," there should be a version number.

Note from the Author or Editor:
This is at the bottom of page 274 in printings after Sep-2017. It's not an errata and the suggested change is invalid, but to avoid potential confusion, let's change the text:
"(it reads almost the same in Python,"
to:
"(the Python code reads almost the same as its natural-language description,"
It looks like the expansion won't change paging, but please let me know if it does.

[Discussion only follows] This is not an errata, but I think the intent of the parenthesized remark was missed and merits the elaboration. It wasn't about Python 2.X/3.X differences, but only a note that the Python code is very close to its preceding English description. In fact, this code runs the same on 2.X and 3.X, so version is irrelevant here (as is strongly implied by the "In Python 3.X and 2.7," at the start of this paragraph):

~$ python
Python 2.7.10 (default, Oct 23 2015, 19:19:21)
>>> D = {k: v for (k, v) in zip(['a', 'b', 'c'], [1, 2, 3])}
>>> D
{'a': 1, 'c': 3, 'b': 2}

~$ python3
Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 26 2016, 10:47:25)
>>> D = {k: v for (k, v) in zip(['a', 'b', 'c'], [1, 2, 3])}
>>> D
{'a': 1, 'c': 3, 'b': 2}

The ordering of the result is prone to vary per run, version, and platform (per the notebox a few pages earlier, titled "Your dictionary ordering may vary"), but that wasn't the point of the parenthetical remark. Post type changed to clarification, accordingly.

"which simply means objects that generate result items one at a time"

should read

"which simply means that objects generate result items one at a time"

("objects that" --> "that objects")

Note from the Author or Editor:
[No changes required] No, this clause is meant to define the italicized "iterables" that immediately precedes it. The "objects" corresponds to the "iterables" directly:

View objects are _iterables_, which simply means objects that generate...

Please read the entire sentence in this light: if it still seems off, feel free to follow up.

Following up on the discussion for:

"which simply means objects that generate result items one at a time"

I now understand your phrasing. It is admittedly minor, though I do think the syntax is slightly ambiguous, and it did trip me up when reading. Obviously it’s not worth tussling over, though I might recommend any of these changes, if you like:

"View objects are *iterables*—objects that generate result items one at a time..."

"View objects are *iterables*, that is, objects that generate result items one at a time..."

"View objects are *iterables*, i.e., objects that generate result items one at a time..."

"View objects are *iterables*, which simply means they are objects that generate result items one at a time..."

(This is near the top of p.276 in newer editions)

Note from the Author or Editor:
[No edits required] Thanks for your follow-up. All of your alternative wordings are reasonable, and I'll leave this for other readers to draw their own conclusions. As an author, I'd only add that if every sentence in this book was so thoroughly scrutinized, there probably wouldn't be a book at all.

Version: Digital Google Play Book.
The Answer #6, to quiz of Chapter 7, explains that the total character count is:

"SIX. The string 'a\nb\x1f\000d' contains the characters a , newline ( \n ), literal value 31 (a hex escape \x1f ), literal value 0 (an octal escape \000 ), and d . Pass the string to the built-in len function to verify this, and print each of its character’s ord results to see the actual code point (identifying number) values. See Table 7-2 for more details on escapes."

However, although the total characters are 6 indeed, as the len suggested function checks Ok, in the detail character list explain below seems to be missing the character "b".

As a way to check this fact I've tried the instruction:
>>>str(len("a"))+'-'+str(len("\n"))+'-'+str(len("b"))+'-'+str(len("\x1f"))+'-'+str(len("\000"))+'-'+str(len("d"))
and the output is:
'1-1-1-1-1-1'

Thanks for your answer with an explanation.

Carlos

Note from the Author or Editor:
REPRINTS: this is in the solution to exercise 6 on page 246 of recent printings (and 238 earlier). It looks like this broke in an earlier reprint. To fix, change the text at the end of the first line of solution 6 from:
newline (\n), literal value
to the following, putting back the former literal-font "b" which was cut:
newline (\n), b, literal value
This shouldn't change page breaks.

DISCUSSION: you're right - the description is missing the "b." In this case, the "b" was there in the original published book, but was inadvertently removed when an unrelated edit was applied to this sentence for a prior reprint.

This apparently broke some time around October 2016, but went unnoticed until your report. For context, see the 'before' screenshot of the book's earlier PDF which had the "b," and the current 'after' PDF which does not:

learning-python.com/lp5e-page246-before.png
learning-python.com/lp5e-page246-after.png

This is not about finding fault, and glitches happen, of course (no, really: this round of updates has also uncovered bugs in Mac OS and a program example, plus the usual set of silly typos that went unnoticed for seven years). The good news is that, thanks to your report, we'll be able to put back the cut "b" in the next reprint, set for early June 2020.

Add a new line to the end of the first output listing on this page that appears just before heading "Handling Errors with try Statements". This new final line should contain a single word, "Bye", non-bold and without quotes. The last 3 lines in this listing will be this (with only "stop" bold, and similar to other output listings nearby):

100
Enter text:stop
Bye

[Discussion] This was reported by a reader by direct email; my reply with description follows:

I appreciate your report on this. You are correct, of course: the code listing on page 332 has a final "Bye" print statement, whose output does not appear in the output listing following it on page 333. I'll add an errata note to patch this in reprints.

This isn't critical, as the "Bye" does appear in the first such example in this section on page 331-332, and again in some later variations' output listings on pages 335 and 336. It could be argued that it's not necessary to show the complete output at each such variation, especially after the first establishes the pattern. But I agree that it would be better to be consistent about this throughout the section.

For the record, the "Bye" output line was also missing in the 4th Edition for this same mid-section example, but went unreported; this might underscore its relatively low priority.

> -----Original Message-----
> im wondering about something in your book
> first of all see the "first" photo attached
> the last statement {print('Bye')} thats means when the while loop ends its must print 'Bye'
> But on the other hand .. check the 'second' photo attached
> at the end when the user typed stop the loop ends and 'bye' was missed
> now am i right ?!
> these at (Chapter 10: Introducing Python Statements)
> page 322
> thanks!

You describe assignments in two ways:

1) "in the second line of Table 11-1, the name spam is assigned the string 'yum'"

2) "and the name ham is bound to the string 'YUM'"

This makes it sound like there's a difference between assigning a string and binding a string. I suggest you remove "is bound" in the second case.

Also, you say "any sequence of names can be assigned to any sequence of values". I think this is backwards. Shouldn't this be

"any sequence of values can be assigned to any sequence of names"

or maybe simply removing one word

"any sequence of names can be assigned any sequence of values"

Note from the Author or Editor:
I agree with one point in this post: the equivalence of "bind" and "assign" could be spelled out explicitly. To tighten up, near the end of the first complete bullet item on Page 340, change:
"""
all these contexts simply bind names to object references at runtime.
"""
to the following, using italics font for the "bind" (this is its first appearance):
"""
all these contexts simply bind (i.e., assign) names to object references at runtime.
"""

Both assign and bind are used interchangeably in the Python world, and the book reflects this vocabulary intentionally. The rest of this post, while appreciated, seems personal preference on minor wording alternatives.

You state here and in the second-to-last paragraph on page 350 that there is an augmented assignment statement for every binary expression operator, but should "every" be "most" or "many"? Are there augmented assignment statements for the comparison operators such as > ?

Note from the Author or Editor:
[On pages 351 para -2 and page 361 para 2 in printings on or after Sep-2016]
This was meant informally, but for the sake of more literal readers, please change the first to the second in both of the following places:

1) Page 351/341 (reworded)
"There is one augmented assignment statement for every binary expression operator in Python."
"As we'll see, there is one augmented assignment statement for most binary expression operators in Python."

2) Page 361/350 (every=>most, operator=>operators):
"As shown in Table 11-2, there are analogous augmented assignment forms for every Python binary expression operator"
"As shown in Table 11-2, there are analogous augmented assignment forms for most Python binary expression operators"

Discussion: I'd use "mathematically-oriented binary expressions" to narrow the set, but that's not quite right, as some have multiple meanings (e.g., '+' for addition and concatenation), and all can be defined to do anything at all by classes. The second instance above is less confusion-prone, as it shows up just after a table of these operators.

Not an error, but for clarity, expand this sentence:
"""
In fact, if you enjoy working harder than you must, you can also code print operations this way:
"""

To the following, adding only the parenthesized text just before the colon, with links to the two referenced chapters -- and please let me know if this changes page breaks; I'm hoping to avoid that:
"""
In fact, if you enjoy working harder than you must, you can also code print operations this way (per Chapters 4 and 9, a 3.X-only return value is omitted here):
"""

[Discussion only follows] A reader wrote by email:
>
> This is on page 357 of the Ebook; page numbering doesn't seem
> to match the print edition. Looking at the last example before the
> "Manual stream redirection" subheading in chapter 11:
>
> >>> import sys
> >>> sys.stdout.write('hello world\n')
> hello world
>
> The system call of course returns a result, and when run
> interactively the result is also printed. As such, when running this
> example under Linux an additional line is added:
>
> >>> import sys
> >>> sys.stdout.write('hello world\n')
> hello world
> 12
>
> where the "hello world" is the text written and the "12" is the result
> of the sys.stdout.write() call. I couldn't find any mention of this on
> your or O'Reilly's errata pages. The omission could be deliberate,
> but some people would find the extra line confusing. I would
> expect the Windows version would add a similar line. There is
> also no mention of this in the following text (i.e. that print always
> returns None where write() returns the number of characters
> written).

Sure, but this isn't platform specific, and is probably not an issue for most readers. The return value of the file's write method is well documented in general file coverage earlier in the book -- starting on Page 122, and spanning Chapters 4 and 9, including the blanket note on Page 288 that reads this way:

"... (for space, I'm omitting byte-count return values from write methods from here on):".

Still, this seems a potential point of confusion, especially for non-linear readers using 3.X. To clarify, I'm suggesting the addition of another parenthetical note about the deliberate omission of the return value in this section, as described above. Such reminders risk becoming overly redundant, but this one seems justified.

After the last sentence on this page, there is a superscript "1" to refer to a footnote. However, the footnote itself is located at the bottom of the next page, 380.

(I am not entirely sure this is an error - please remove this erratum if it is not.)

Note from the Author or Editor:
Confirming this; it's a bit confusing as is, but it's fairly minor, and we'll have to see how it impacts paging if the footnote is moved to the referencing page.

the sentence 'indent all but the simplest of blocks', what does the book mean with "the simplest of blocks"? Which are the "simplest of blocks" it refers to?

Note from the Author or Editor:
[No changes required] The phrase "simplest of blocks" refers to a nested block that's composed of one or two simple, non-compound statements that are not indented, but coded on the same line as the statement header. It's generally consider bad style to do this when the unindented block's statements are non-trivial, as it can lead to code that's difficult to read and change.

Retained as a clarification, but no change required in the book. The page 380 text is an intentionally brief summary wrap-up of the second section that discusses nested block syntax, exceptions, and style. By this point in the book, both the meaning and disfavor of coding all but the "simplest of blocks" unindented have been discussed.

For example, the section on Page 329, and the multiple-page example which follows it, discuss and illustrate both this topic and the advice. I appreciate the question, and readers who jump to Page 380's wrap-up at random might indeed find it terse; but some extra research can help clarify topics covered in more depth earlier in the book.

Another word break issue:

con - tinue broken across 2 lines.

There is another one on page 391, 2nd main paragraph.

Note from the Author or Editor:
Minor and cosmetic, but yes -- both of these should be fixed in the print version if possible. Do not split the "continue" keyword literal; force its "con" to the start of the next line, and verify that other literals in these paragraphs are not split in the process.

See also notes on pages 98 and 102 for similar items and more background. There are almost certainly more of these on later pages, but it's been a longstanding O'Reilly style, whether explicit policy or tool artifact. Given that this hasn't drawn more reader posts, it doesn't seem worth an exhaustive scan at this time.

"[line.rstrip() for line in open('script2.py') if line.rstrip()[-1].isdigit()]"

The code raises an IndexError in Python 3.3.2 and 2.7.5.

Note from the Author or Editor:
[Not an errata, but retained as a clarification, with a minor supplemental insert]

CHANGE the last line of paragraph 2 on page 428 from:
"expression on the right side:"
to this, where [-1] and [-1:] are literal/fixed font:
"expression on the right side (replace [-1] with [-1:] for files with blank lines):"

DISCUSSION: This code works correctly and as shown when run on the 4-line test file whose content is given at the start of this section and implied by all the other examples here. See the first example on page 426:

>>> f = open('script2.py')
>>> lines = f.readlines()
>>> lines
['import sys\n', 'print(sys.path)\n', 'x = 2\n', 'print(x ** 32)\n']

If you use this same 4-line test file, the example in question works properly:

C:\code> type script2.py
import sys
print(sys.path)
x = 2
print(x ** 32)
C:\code> py -3
>>> [line.rstrip() for line in open('script2.py') if line.rstrip()[-1].isdigit()]
['x = 2']

That said, running this code on a file whose content is different than that shown in the book may indeed raise the exception, if the file used includes a blank line. This can occur because [-1] on an empty string triggers IndexError. Although this is a different context than that used in the book, the code could be easily generalized to allow for empty lines too, by slicing instead of indexing, like this:

>>> [line.rstrip() for line in open('script2.py') if line.rstrip()[-1:].isdigit()]
['x = 2']

This works more robustly, because, as explained in the book, slicing a string always returns a string, and slices scale themselves to be inbounds but indexing does not:

>>> 'abc1'[-1], 'abc1'[-1:]
('1', '1')
>>> ''[-1]
IndexError: string index out of range
>>> ''[-1:]
''

For background on such things, see the book's types part and exercises.

After "import docstrings", there is the output from the previous code snippet, "print(square(4))
print(square.__doc__)"

Note from the Author or Editor:
[No edits required - retained as info only] This example and its output is correct as is. The output listed after the ">>> import doscstrings" line is the intended result of the two print() lines at the bottom of the docstrings.py file.

The two print()s are top-level code, which means they will be run when the file is first imported as a module (just like when it's run as a script). That's just how Python modules work: the first import runs all the file's top-level code, which usually creates functions and classes to be used later, but may also trigger print() statements to generate output, as in this file.

That said, this example might confuse some readers because:

1) There is no output when the file is imported again later in the section (but also correctly: top-level code runs on first import only).

2) It may be a bit early in the text to assume module-file knowledge like this for random-access readers. Module basics like this are covered earlier in some depth in the section "Module Imports and Reloads" of Chapter 3, but not all readers work linearly.

Hence, I'm retaining this post as clarification for others. For more details on modules, see the Chapter 3 first look, as well as the fuller coverage in Part V.
The TOC and Index can also help if you're just flipping about the book.

The author used the word "sport" in various places. In the following sentence (on page 495) "As one consequence, a single function can
often be applied to a variety of object types—any objects that sport a compatible interface (methods and expressions) will do, regardless of their specific types."

Also on page 1131, second paragraph, "Moreover, 3.X sports slightly
modified syntax for the raise statement and except clauses, some of
which is available in 2.6 and 2.7."

On papge 1143, "Since an
else always requires an except, this nested form even sports the same mixing constraints of the unified statement form outlined in the preceding section."

I am wondering if the author intended to use the word "support" rather than "sport"?

I googled the English word "sport" and it does mean "wear or display (a distinctive or noticeable item)." Is it the meaning the author intended to use?

Note from the Author or Editor:
[No edits required] The use of "sport" in these contexts is intentional, and is indeed the last form you found -- to "wear or display (a distinctive or noticeable item)." In other words, it's a feature or attribute of the subject. That said, other readers have asked about this in the past too, so I'm retaining this note as a clarification here.

[Assigning to argument names inside a function does not affect the caller.]
Argument names in the function header become new, local names when the function runs, in the scope of the function.

should be:
...Argument names in the function header become new, local names when the assignment is executed,...

Note from the Author or Editor:
[Not an errata, no change required]

I'm passing on this because the text is as it should be, but keeping the reply as a clarification-only note. This introductory preview paragraph makes the point that assignments to function argument names within a function's body have no effect on the caller. As described later in this chapter, argument names are automatically assigned to the values passed into the function, and are created when the function call begins. Unlike other locals, argument names do not become local variables when later assign inside the function; by that point, they already exist by virtue of the automatic assignment that occurs as arguments are passed in. This paragraph is about the fact that _later_ assignments to these names don't impact the caller -- as opposed to in-place changes to argument objects, the next paragraph's point. Subtle, perhaps, but explained in full later in this chapter; this text is just a preview.

The text says, "This seems like an implementation artifact that is prone to change." Why would it be prone to change? People can trip over it if they're not paying attention, but without it, factory functions can't act as closures. Here's an artificial example:

#!/usr/bin/env python3

def makeMore():
def changer(y):
nonlocal i
i = y
return y
acts = []
for i in range(5):
acts.append(lambda x: i**x)
acts.append(lambda x: changer(x))
return acts

more = makeMore()
print(more[0](2))
print(more[1](2))
print(more[2](2))
print(more[4](2))
print(more[5](20))
print("not a bug, but a feature:")
print(more[0](2))
print(more[1](2))
print(more[2](2))
print(more[4](2))

If they change it, no more closure functionality in factory functions. That would break code (including mine) that takes advantage of this. Haven't they broken enough code already?

Note from the Author or Editor:
REPRINTS: Please change the referenced:
"This seems an implementation artifact that is prone to change, and may become"
to:
"This may seem an odd special case, but it reflects Python's implementation of variable scopes, and will become"
This is on page 507 in earlier reprints; it looks like this won't impact page breaks.

[DISCUSSION]. First off, please note that the text's statement you called out is not about closure state retention in general, but pertains only to passing default argument values to retain the current value of loop variables in an enclosing scope (this should be clear from its context). Your example doesn't do this; it uses nonlocal to modify an enclosing-scope variable manually, but it doesn't retain the value which the variable had at function-creation time.

In fact, the "i" in all the loop-generated functions in your code refers to the same, shared "i"; this is the exact limitation which the book's code works around. By ensuring that each function's "i" is unique, the book's code retains the current-loop value of each "i" in its own variable. There are lots of ways to code and use closures, and your example may have valid use cases; but it is not equivalent to that in the book, and misses its point. This is very subtle business, so please retrace the two examples for yourself.

That aside, the comment about defaults here reflects their history. As noted in the book, prior to nested scopes (and the later nonlocal which makes them changeable), closures in Python used default variables to explictly pass in each enclosing-scope value they used. This worked, but was odd and clumsy.

When enclosing scopes were added, they were meant to obviate this technique, but their implementation left holes that must still be plugged today; the default-arguments coding shown in the book's loop example is the standard work-around. This crops up frequently enough in GUIs to qualify as gotcha (and it does on page 683); seems like an implementation oversight that may be resolved in the future (e.g., by an option to save non-locals per function); and the rate of flux in Python 3.X makes change a not-bad bet.

Still, a change in closure semantics to address this use case seems less likely with every new Python release that ignores it. Because the odd default-arguments special case may now very well be permanent, I'm going to make the limited change above. But if this is tweaked in next years' 3.X release, I reserve the right to issue a hearty "I told you so"...

(Book uses different font for function names. I replaced it with single quotes below.)
"This code relies on the fact that the function name 'nested' is a local variable in the 'tester' scope enclosing 'nested'; as such, it can be referenced freely inside 'nested'." <- The last word has to be 'tester'

Note from the Author or Editor:
[No changes required] I understand the confusion, but the 'nested' at the end of this sentence was intended and is correct. The 'nested' function relies on the fact that its own name is accessible to its code, because it is nested in 'tester', and nested functions automatically see the scopes of all enclosing functions by virtue of Python's normal LEGB variable-lookup rule.

This is underscored by the example's comment "# nested is in enclosing scope" in the 'nested' function. You're right that 'tester' can access 'nested' too (and does); but the point here was about the name's accessibility inside 'nested' due to the enclosing scope; when 'nested' later runs "nested.state += 1", it's relying on finding the leftmost name in 'tester' left by the function def, even though 'tester' has returned and exited. That is, this is a closure function which remembers 'nested' from the enclosing 'tester' scope.

This is quite subtle even with this clarification, so I'm retaining this as an author note for others puzzling over this example too.

In "Technically, it was added" the word "it" seems to refer to the unpacking call syntax form, but does it actually refer to the apply function?

Note from the Author or Editor:
[On page 559 para 2 in printings on or after Sep-2016]
The parenthesized sentence referred to is ambiguous as noted, but also confused in general, as its "it" spans two subjects (a last-minute patch, most likely). To fix it, please change the original:
"""
(Technically, it was added in 2.0, was documented as deprecated in 2.3, is still usable without warning in 2.7, and is gone in 3.0 and later.)
"""
to the following (and let me know if this changes the page-break here--I've reworded to try to avoid expansion):
"""
(Technically, the syntax was added in 2.0; the function was deemed deprecated in 2.3, is still usable without warning in 2.7, but is gone in 3.X.)
"""

for:

>>> def f(a, *b, c=6, **d): print(a, b, c, d)

the second test works in recent version of Python:

>>> f(1, *(2,3), **dict(x=4, y=5), c=7)
1 (2, 3) 7 {'y': 5, 'x': 4}

>>> sys.version
'3.5.0 (v3.5.0:374f501f4567, Sep 12 2015, 11:00:19) \n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]'

Note from the Author or Editor:
[Not an error, no fix required, type changed to clarification]

This post refers to Python behavior that has changed since this edition was published. The new behavior appeared in Python 3.5, in September 2015. Because this June 2013 edition is based on 3.3, I'm not going to wedge this in (this edition can't accommodate every post-publication Python change). I am, however, changing this post to a clarification for other readers who may have the same query.

The example (in the second code section of page 541 in the most recent printing) fails as shown in the book on 3.3:
C:\code> py -3.3
>>> def f(a, *b, c=6, **d): print(a, b, c, d)
...
>>> f(1, *(2, 3), **dict(x=4, y=5), c=7)
SyntaxError: invalid syntax

But as you noted now works on 3.5 and later without error:
C:\code> py -3.5
>>> def f(a, *b, c=6, **d): print(a, b, c, d)
...
>>> f(1, *(2, 3), **dict(x=4, y=5), c=7)
1 (2, 3) 7 {'y': 5, 'x': 4}

This is due to a relaxing of argument ordering rules that coincides with generalized * unpackings in 3.5, and is alluded to in this post on my recent Python changes page:

http://learning-python.com/books/python-changes-2014-plus.html#s354

On page 545 under heading 'Generalized Set Functions': the text reads "Here is a version that intersects an arbitrary number of sequences (one or more) by using the varargs matching form *args to collect all the passed-in aguments..."

However the code example does not return an expected results. Example. s1, s2, s3 = 'spam', 'slam', 'pppp'

intersect(s1,s2,s3)
...
[ ]

Note from the Author or Editor:
[Not an error, no fix required, changed type to clarification only]

This code works correctly under both Python 3.X and 2.X, and the '[]' empty list output is correct for your example, because there are no items in common. Perhaps you misunderstood what intersection means? It's described in multiple locations: see pages 400, 480, 545, and later. The variant on page 545 picks out items in common among all arguments, which, in your test example, is none.

Also, make sure the "else" is aligned vertically with the nested "for", and not the "if", as it is associated logically with the "for" -- where it's run on the way out of the loop, if no "break" was reached. Here's the code and its behavior, sans its comments (which align poorly on this page):

def intersect(*args):
res = []
for x in args[0]:
if x in res: continue
for other in args[1:]:
if x not in other: break
else:
res.append(x)
return res

s1, s2, s3 = 'spam', 'slam', 'pppp'
print(intersect(s1, s2, s3)) # => [], no items in common

s1, s2, s3 = 'spam', 'slam', 'pappmp'
print(intersect(s1, s2, s3)) # => ['a', 'm'], 2 items in common

The sentence: "but also allows us to pass in optional keyword arguments to specify a dictionary sort key and a reversal flag, which.....".

I think that 'dictionary sort key' is too ambiguous, in fact according to the documentation: "key specifies a function of one argument that is used to extract a comparison key from each list element"

So in my opinion it should be more clear.

Note from the Author or Editor:
This is covered earlier, but to avoid confusion, let's add a word -- Page 55, paragraph -2, middle of line 2, change the first of these to the second:

"a dictionary sort key"
"a dictionary sort key function"

[Discussion only follows]
Actually, the book also makes this pretty clear in the full section on the subject earlier, which is back-referenced here. Did you try following the link in the book here before going to Python docs? It points to Chapter 8, where Page 247 says:
"""
the key argument gives a one-argument function that returns the
value to be used in sorting ...
"""
and then demonstrates this live. That said, a 1-word augmentation seems harmless and useful here.

In the example of computing the minimum value. In the "goal" (p. 562) it states "the function should accept zero or more arguments...".
But the proposed code expects at least one argument.

Note from the Author or Editor:
[No reprint edits required] I'm changing this to a clarification to save it for other readers who may have the same question. This is on page 542 in earlier printings.

While the post is not incorrect, it seems to discount some of the larger points of the solution shown. The solution actually _does_ accommodate zero arguments, by letting Python detect and raise an error -- a completely valid response, given then min() really has no meaning if no arguments are passed in, and there is no valid result if any Python data type is allowed (should the result be 0? ''? None?...). In fact, this is called out by the book explicitly just after the code:

"""
Notice that none of these three variants tests for the case where no arguments are passed in. They could, but there’s no point in doing so here—in all three solutions, Python will automatically raise an exception if no arguments are passed in. [...] This is exactly what we want to happen—because these functions support any data type, there is no valid sentinel value that we could pass back to designate an error, so we may as well let the exception be raised.
"""

In other words, the zero-argument case is handled, and as best it can be. Less than fully rigorous, perhaps, but Python is not mathematics, and exceptions are not crashes -- they are a well-defined way to handle program conditions. And they are a full-points solution in my book.

We have space to augment a footnote on this page with a few key and useful summary details. On Page 567, at the end of the footnote on this page, change:
"
lambda is simpler to use than you may think.
"
to the extended:
"
lambda is simpler to use than you may think: it's simply an alternative way to code a function, albeit without full statements, decorators, or 3.X annotations.
"

A reader sent this by direct email. The wording of this paragraph follows Python's own help for reduce(), but is potentially confusing, as it may be read as referring to argument order, rather than values operated on in general. Let's tighten this up as follows; change:
"""
The built-in reduce also allows an optional third argument placed before the items in the sequence to serve as a default result when the sequence is empty,
"""
to this (there seems to be ample space in this paragraph to avoid repaging):
"""
The built-in reduce also allows an optional third argument, effectively placed before the items in the sequence to serve as an initial value and a default result when the sequence is empty,
"""

It seems to me that the chapter title "Comprehensions and Generations" should probably be "Comprehensions and Generators".

I don't believe "generation" has any significant meaning within Python syntax, and if it does, I don't think it's defined in this book. Moreover, the term "generator" appears numerous times with multiple index entries. Lastly, as a crude metric, a Google search for "python generations" returns about 800 results, whereas "python generators" returns 40,000.

Note from the Author or Editor:
[No changes required--retained as a note] No, this title was crafted this way on purpose, in the name of a form of alliteration often called assonance or end rhyme (think rap for an example). You might prefer the more technically tight "Generators" here, and I appreciate your assertion. But, being a writer, I'm prone to turn words for fun over formality this way now and then.

And FWIW, the term "generators" shows up 132 times in the book -- including a few times in the introductory paragraph immediately following the title in question. "Generations" is just in the title, and I suspect most readers get the play on words. I also suspect that a book written to strictly conform to Google search results wouldn't be one worth reading, but YMMV.

There's a minor extension in 3.3 regarding return statements in generator functions that was omitted in the book due to its obscurity, but has potential to confuse if it shows up in code over time. If we can squeeze it in without impacting page breaks badly, I'd like to add a clarifying footnote.

THE CHANGE:

On Page 594, add a footnote reference to the very end of the first sentence:
"""
To end the generation of values, functions either use a return statement with no value or simply allow control to fall off the end of the function body.*
"""

with this footnote text at page bottom (its "StopIteration" is literal font, and it looks like the next 2 pages have room to absorb the insert; let me know if shortening is needed to avoid changing page breaks for the rest of the chapter):
"""
* Technically, Python treats return statement values in generator functions as syntax errors in 2.X, and in all 3.X prior to 3.3. As of 3.3, a return statement value is allowed and attached to the StopIteration object, but the value is ignored in automatic iterations contexts, and using this makes code incompatible with all prior releases.
"""

def permute2:

I think there should be a set of brackets around
seq [I:i+1] + x so that it reads

yield(seq[I:i+1] + x)

not sure why but I can't get it to work otherwise

Note from the Author or Editor:
[Informational only: not an errata, no change required.] This example's code (list-builder and generator-based recursive permutations) works as shown in every Python I've tested, from 3.3 down to 2.3; prior to 2.3, yield wasn't available by default:

>>> import sys; sys.version
'3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) ...'
>>> from permute import *
>>> permute1('abcd') == list(permute2('abcd'))
True
>>> len(list(permute2('abcd'))), 4*3*2*1
(24, 24)

>>> import sys; sys.version
'2.3 (#46, Jul 29 2003, 18:54:32) ...'
>>> ..identical behavior...

Yield morphed from statement to expression in 2.5 to support sends (and sometimes must be enclosed in parenthesis in this role), but it never was required to use function call-like parenthesis.

I can't tell what the issue may be, but make sure you're running the exact code in the book (or its examples zip file); the post has mixed case for variable "i" which would fail, but this may be just in the post.

For more yield background: see Pages 137-138 (expressions), 320-321 (statements), 353-354 (reserved words), and most of Chapter 20 (generators).

In the first code snippet:
>>> from permute import permute1, permute2
>>> seq = list(range(10))
>>> p1 = permute1(seq) # 37 seconds on a 2GHz quad-core machine
# Creates a list of 3.6M numbers
Here, it creates a list of 3.6M numbers, But I have got the size of `p1` through `sys.getsizeof(p1)`. In my environment, it returns '31774880' in bytes, then convert it to megabytes, it will be around 30M numbers. There is much gap between 30M and 3.6M. So the memory usage maybe wrong.

Note from the Author or Editor:
[No change required; informational only]

I think you may be confusing the logical number of list items (referred to in the book: 3.6M) with the physical size that such a list requires in memory (not discussed in the book). The len() function returns the former, but sys.getsizeof() returns the latter--the size in memory of an object itself, but not the items it may refer to. On a Mac, using Python 3.5, the number of items in the result is 3,628,880 (3.6M) as advertised:

>>> import math
>>> from permute import permute1, permute2
>>> math.factorial(10)
3628800
>>> seq = list(range(10))
>>> p1 = permute1(seq)
>>> len(p1), p1[0], p1[1]
(3628800, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9], [0, 1, 2, 3, 4, 5, 6, 7, 9, 8])

But the physical size is much more difficult to account for, given the overheads of object storage in memory. The total memory space for the 3.6M-item list is 31,774,872 (31M) bytes, as you found:

>>> import sys
>>> sys.getsizeof(p1)
31774872

However, the storage of Python lists cannot be directly compared to that of an array of integers in a C-level language. In Python, even simple integers can consume 28 bytes in memory:

>>> sys.getsizeof(1)
28
>>> sys.getsizeof(p1) / sys.getsizeof(1)
1134816.857142857

This still is meaningless, though, because the list's referents are not included in its space total, and it's difficult to pin down the size of both integers and lists:

>>> sys.getsizeof(0), sys.getsizeof(1)
(24, 28)
>>> sys.getsizeof([]), sys.getsizeof([1]), sys.getsizeof([0, 1, 2, 3])
(64, 72, 96)

If you stare at this long enough, you'll probably notice a pattern: lists seems to add 8 bytes for every item after the first:

>>> sys.getsizeof([0] * 10)
144
>>> (sys.getsizeof([0] * 10) - 72) / (10-1)
8.0

This can be used on the permute result list's length to get closer to the physical memory size reported by getsizeof():

>>> len(p1) * 8
29030400
>>> sys.getsizeof([1]) + ((len(p1)-1) * 8)
29030464
>>> sys.getsizeof(p1)
31774872

But it's still not enough (29M versus 31M). Lists use optimization techniques internally (like increasing over-allocation to allow for future expansion), and you'd have to study the C source-code implementation to truly understand the space used--which is why this topic wasn't covered in the book. As an approximation, it's fairly safe to say that a list of N items takes roughly 8 bytes per item, plus some extra overhead. Hence the 31M space for 3.6M items, though finer-grained precision requires finer-grained analysis.

Incidentally, this example still takes about the same amount of runtime today, on a 2015 Macbook Pro running a Core I5 (the book's 37 seconds was on an older I7 from 2012 on Windows; at least in terms of raw CPU speed, times haven't changed much):

>>> import time
>>> def run():
... start = time.perf_counter()
... p1 = permute1(seq)
... print(time.perf_counter() - start)
...
>>> run()
35.37005175699596

Three minor edits, inspired by a reader's email described ahead, and largely for Python 2.X readers to alert them to a version difference:

1) On page 617, extend the end of the first paragraph on the page, from:
"""
zip pairs them up:
"""
to this, with "zip", "map", and "None" in literal font:
"""
zip pairs them up (3.X's map truncates shorter iterables; 2.X pads them with None):
"""

2) On Page 617, extend line 13 of code listing section #1, from:
"""
>>> list(map(pow, [1, 2, 3], [2, 3, 4, 5])) # N sequences: N-ary function
"""
to this, adding ", 3.X" and retaining the current vertical alignment of the "#":
"""
>>> list(map(pow, [1, 2, 3], [2, 3, 4, 5])) # N sequences: N-ary function, 3.X
"""

3) On page 618, at the start of code listing section #4 that reads:
"""
# Using generators: yield and (...)

def mymap(func, *seqs):
res = []
for args in zip(*seqs):
yield func(*args)
"""
delete the entire 3rd line that reads "res = []" (only). This line was copied from the prior version, and is not needed in this version. The code should now read as follows (and hopefully doesn't change paging too much):
"""
# Using generators: yield and (...)

def mymap(func, *seqs):
for args in zip(*seqs):
yield func(*args)
"""


[DISCUSSION only follows:]

A reader wrote to ask why this example on Page 617 of Chapter 20:

>>> list(map(pow, [1, 2, 3], [2, 3, 4, 5])) # N sequences: N-ary function
[1, 8, 81]

works on Python 3.X, but fails in 2.X. This reader later withdrew the query, after finding the earlier 2.X map() coverage which notes its None padding when argument lengths differ (by contrast, 3.X's zip() and map() both truncate). This earlier coverage is on Page 408-409, in Chapter 19's section "map equivalence in Python 2.X."

In hindsight, though, the Chapter 19 section (and related material later in Chapter 20) is perhaps not as clear about the 2.X/3.X differences in the map() call as it could have been. Really, the padding with None always occurs in 2.X, _irrespective_ of the function argument passed in. In full detail:

* IN PYTHON 3.X, map() always truncates at the shortest argument's length, and a real function is expected in its first argument:

C:\...>py -3
>>> list(map(pow, (2, 3), (1, 2, 3))) # 2**1, 3**2
[2, 9]

>>> list(map(pow, (2, 3, 4), (1, 2))) # 2**1, 3**2
[2, 9]

>>> list(map(None, (2, 3), (1, 2, 3)))
TypeError: 'NoneType' object is not callable

* IN PYTHON 2.X, map() always pads shorter arguments with None, regardless of whether a real function or None is passed -- which can lead to errors for functions that don't expect the None:

C:\...>py -2
>>> list(map(pow, (2, 3), (1, 2, 3))) # 2**1, 3**2
TypeError: unsupported operand type(s) for ** or pow(): 'NoneType' and 'int'

>>> list(map(pow, (2, 3, 4), (1, 2))) # 2**1, 3**2
TypeError: unsupported operand type(s) for ** or pow(): 'int' and 'NoneType'

>>> list(map(None, (2, 3), (1, 2, 3)))
[(2, 1), (3, 2), (None, 3)]

This is why Page 617's "list(map(pow, [1, 2, 3], [2, 3, 4, 5]))" works in 3.X (as shown) but fails in 2.X (as not shown): on 2.X, the last function call runs "None ** 5" and fails.

In addition to 2.X map() coverage on Page 408-409, this 2.X behavior is strongly implied by the manual zip() and map() implementations that immediately follow in Chapter 20. Still, the extension to a real function argument isn't stated explicitly in either location.

Also note that the 2.X-flavor map() implementation in Chapter 20's section "Coding your own zip(...) and map(None, ...)" is really just that of 2.X's map(None,...), as it does not apply a function to paired items (though you could easily extend it to do so). This example primarily implements a zip() with padding.

For more on map() in Python 3.X and 2.X, see also Python Pocket Reference 5th Ed. (a supplement to Learning Python), as well as Python's standard library manual. As a tutorial, Learning Python occasionally sidesteps some obscure or dated fine points on purpose; this qualifies on both counts (mapping functions on differing-length iterables in 2.X seems rare in the extreme), but the book example's potential to confuse merits the patches.

I think, you should insert “print(i)” before “X=yield i” to be compatible with the outputs below the code.

Note from the Author or Editor:
[No changes required]. No, the output matches the existing code exactly. Have you tried running it yourself? It's complex because the output reflects _both_ the explicit print(), and the automatic display of return values at the interactive prompt. Let's dissect the code; the initial def:

>>> def gen():
... for i in range(10):
... X = yield i
... print(X)

makes a generator that will both yield results, and receive and display values sent from a caller. When the generator itself is called, it doesn't run the def's code, but simply makes and returns an iterable object with a send() method:

>>> G = gen()

On the first next(), the generator starts the for loop and runs up to the first yield; the yielded value is then automatically displayed at the interactive prompt as usual ("0"):

>>> next(G)
0

But here's the odd bit: when a value is sent to the generator by send(), the generator resumes execution after the yield, which also returns the sent value; the sent value is assigned to X and explicitly printed within the generator ("77"); but the generator then proceeds on to the next for-loop iteration and yields the next result, which is automatically printed at the interactive prompt ("1"):

>>> G.send(77)
77
1

And so on for later sends (if next() is called instead, it simply sends None):

>>> G.send(88)
88
2
>>> next(G)
None
3

Trace on your own if this still isn't making sense. I'm retaining this reply as a clarification for other readers who may be confused by this example too. Generators are mind-bending stuff on a good day.

The implicit code for the zip emulator in this section seems broken on my version of Python.

Python 3.7.4 (default, Jul 9 2019, 16:32:37)
[GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def myzip(*args):
... iters = list(map(iter, args))
... while iters:
... res = [next(i) for i in iters]
... yield tuple(res)
...
>>> list(myzip((1, 2, 3), (4, 5, 6)))
Traceback (most recent call last):
File "<stdin>", line 4, in myzip
File "<stdin>", line 4, in <listcomp>
StopIteration

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
RuntimeError: generator raised StopIteration

Note from the Author or Editor:
[No book changes required] Yep; this reflects a major and dubious change to generator functions made in Python 3.7 which broke much existing code--including this book example. In short, in 3.7 and later, StopIteration can no longer be raised--either implicitly or explicitly--to end a generator. Instead, generators:

1) Must use "return" statements (or, equivalently, fall off a function's body) to terminate the results generation

2) May need to explicitly catch StopIteration (and possibly RuntimeError) instead of allowing it to propagate as in the example

For the fuller story, see the writeup on this at my Python-changes page here:
https://www.learning-python.com/python-changes-2014-plus.html#s372

It's not clear if or how this can be addressed in book reprints--or whether it should be at all. Keeping up with all Python 3.X thrashing seems a monumental task for a print book. Given the lack of space for inserts on these pages, for now I'm going to relegate this to the web page listed above, and also refer readers to Python's "What's New" documents for this and other Python churn (and add this to a growing list of updates should a future edition ever come together).

The book: "The generator functions and expressions of the preceding chapter tend to be slightly slower than list comprehensions, though they minimize memory space requirements and DON'T delay result generation."

I think that "don't"' shouldn't be there, because as the book said previously generators delay results.

Note from the Author or Editor:
No, the text as intended is correct here (see below). But to clarify, let's change the end of the 2nd last paragraph on Page 629 from the first of the following to the second (hopefully this won't change page breaks here; please contact me if it does):

"don’t delay result generation."
"don’t delay the caller for result generation when there are many results to generate."

[Discussion only follows]
Not an errata, though I understand the confusion. Generators do produce results only on request. as covered in the entire preceding chapter. However, the "don't delay" here is referring to the fact that generators won't pause a program to produce results when there are many in the results set, or it takes a long time to produce them; generators return the first result quickly, rather than making the caller wait for the entire results set to be computed all at once.

If that's unclear, please see the permutations case study in the prior chapter, Pages 612-616 -- a non-generator pauses the caller for nontrivial lengths (and perhaps forever), but the generator returns the first result quickly; quoting from this:
"""
The list and generator versions' results are the same, though the generator minimizes both space usage and delays for results.
"""
This was what the "don't delay" meant here.

The code uses time.clock() and refers to Python 3.3. However that function was deprecated in 3.3 (https://docs.python.org/3.3/library/time.html#time.clock) and removed in 3.8 (https://github.com/python/cpython/pull/13270).

Note from the Author or Editor:
[No changes required] I appreciate your input, but this book was written when Python 3.3 was current, and lots of people were using both older versions of 3.X as well as 2.X that didn't have the new tools. Some still do today, despite what you may have heard.

The deprecation status of these time-module functions is clearly described in the sidebar on pages 655-656, which is referenced earlier at the top of page 654 (did you miss it?). That sidebar also gives coding work-arounds to address future deprecation, which, as you note, is now officially complete. Computer books cannot predict the future, but in this case, it was fairly well foreshadowed.

But there's a larger point here. If, as some might wish, this book were updated to include only today's latest and greatest, it would both exclude those using older versions, and be lamented as dated just a few years hence. This requires compromises in both camps. Unfortunately, those bent on changing Python incompatibly have never seemed to be interested in compromise; more on this here:

https://learning-python.com/python-changes-2014-plus.html#s381

That said, time-module differences are ultimately trivial compared to the task of mastering programming at large. Most beginners are best served by learning the fundamentals covered by this book first, and exploring the transient cutting edge later, if and when needed. The details of running aren't all that important until you've learned to walk.

this is very minor, but it would be better to somehow prevent a linebreak in the middle of "C++"

Note from the Author or Editor:
[No changed needed, retained as a note] This occurs on page 703 of older (2015 and earlier) printings only, where its "C++" is split badly by a "\n" newline like this: "C+\n+". This splitting is not present in newer (2016+) printings, where this is on page 727, and its "C++" appears atomically.

Moreover, "C++" is not line-split at any of its 93 occurrences in the latest printings. For the record, the bad "C++" split on page 703 is also the only one of the 93 appearances broken this way in older printings, so this was a rarity.

I agree this is subpar where it crops up, and line splits have been problematic in the past, especially for literal terms. But this particular instance was repaired in later reprints, so there's no action to take on this.

Page 735 calls sys.path the module search path. That's true generally and acceptable informally, but the search path is really only sys.path at the top (left) in absolute imports; in other cases, it may be limited to a package's location, whether that is a regular package's sole directory or a namespace package's __path__.

This should be apparent given the preceding description of package and relative imports and later discussion of __path__ and sys.path's leftmost role, but this terminology may be a bit too loose here, especially following the sections on packages and preceding a formal import algorithm sketch for namespaces.

THE CHANGES:

1) To clarify, in Page 735's paragraph -1 line 2, change this sentence:
"
During imports, Python still iterates over each directory in the module search path, sys.path, just as in 3.2 and earlier.
"
to this, expanding the "sys.path" in the middle, retaining the literal font on "sys.path", and using a normal dash for both of the "--":
"
During imports, Python still iterates over each directory in the module search path--defined by sys.path for the leftmost components of absolute imports, and by a package?s location for relative imports and components nested in package paths--just as in 3.2 and earlier.
"

2) Also, in Page 736's paragraph 5 line 2, change:
"
located via multiple sys.path entries.
"
to this (with no fixed-width font):
"
located via possibly multiple module search path entries.
"

It looks like we have space for both changes without impacting page breaks, but let me know if this won't work.

Was does the book mean with "the timing of path extensions is irrilevant"?

Note from the Author or Editor:
[No changes required - informational only]
This is subtle, but I'll try to clarify here. The full text referred to is:
"""
This is also true if we import through the namespace package name immediately—because the namespace package is made when first reached, the timing of path extensions is irrelevant:
"""
Look closely at the code listings before and after this. The code before imports a root directory (sub), and the code after imports subfolders of the root (sub.mod). The point of this text is that it makes no difference when the subfolder extension is imported or referenced; the root is still a fully-formed namespace package either way. Minor, perhaps, but if this were not so, we'd have to import a root before any of its parts. Also note that namespace packages were new in 3.3, and may or may not see wider use with time.

Not an error, but to avoid confusion, I'd like to edit and call-out an assert usage:

1) In the code listing on page 752, change line 12 from the first of the following to the second, only deleting the single outermost "()" pair (and leaving a single space after "assert"):

assert(digits.isdigit())
assert digits.isdigit()

2) On Page 754, add the following sentence to the end of first paragraph on the page (that ends with "the command line."), with its "assert" in literal font, and a link to Chapter 34:

"For more on the assert statement used here, see Chapter 34."

[Discussion] This code is valid and works as is (the extra outer parens simply enclose an expression), but seems potentially misleading, as it makes assert look like a built-in function; it's a statement, as shown and explained in detail elsewhere (see pages 321, 869, 939, 1086, and primarily 1112-1113).

Great book! And, this is a tiny nit (btw):

This is the page (786) where you introduce the MRO of inheritance and the concept of Left To Right. I could not figure out what decided Left to Right order because there was no code example or explanation until page 789. At first, I glanced ahead a bit to see what I could find, but, did not get to page 789. Google returned this page: "python-history.blogspot.com/2010/06/method-resolution-order.html" (nice explanation)

Maybe a footnote 786 on what determines the let to right ordering or pointer to page 789.

Note from the Author or Editor:
[No reprint edits required] I'm retaining this as a clarification for other readers. This is on page 810 in newer printings.

I understand the post's confusion, but as a friendly suggestion: readers would probably do better by reading (or flipping) three pages ahead in their book, than by bringing up a browser and crawling through the web looking for answers. There's some good stuff online, of course, but judging from my own search results lately, you're just as likely to be misled there as informed. The book's designed to be a linear read; if you stick with it, chances are good that your questions will be answered very soon after they come up.

If you're really in the mood for something online though, a search for "mro" at my website also turns up the following (alas, these are a few pages down in a generic search; I really have to talk to the SEO folks...):

http://learning-python.com/python-newstyle-inheritance.html
http://learning-python.com/book-queries-lp5e.html#q1
http://learning-python.com/PyRef5E-preview--Formal-Inheritance-Rules.pdf

Hi,
I was not able to load the following scripts using the default download script provided. i am using python 3.6.1 and 3.3.0 on Ubuntu 16.04.2 to test.

Errors includes, unable to execute permission, unable to find script/script not found (even when running python on the code directory) and unexpected syntax error even when i was using the downloaded file.

>>> import os
>>> res1 = os.popen('reloadall.py tkinter').readlines()
>>> res2 = os.popen('reloadall2.py tkinter').readlines()
>>> res3 = os.popen('reloadall3.py tkinter').readlines()
>>> res1[:3]
['reloading tkinter\n', 'reloading sys\n', 'reloading tkinter._fix\n']
>>> res1 == res2, res2 == res3
(False, False)
>>> set(res1) == set(res2), set(res2) == set(res3)
(True, True)

Below are the modifications made in order to run the scripts.

1. change the permission for the scripts
chmod 755 reloadall*.py

2. add or replace the shebang for the scripts to include the one below:-
#!/usr/bin/env python

3. when reissue the command on 3.3, i got exactly the same results as the book.
Python 3.3.0 (default, Mar 23 2017, 10:06:39)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> res1 = os.popen('~/code/reloadall.py tkinter').readlines()
>>> res2 = os.popen('~/code/reloadall2.py tkinter').readlines()
>>> res3 = os.popen('~/code/reloadall3.py tkinter').readlines()
>>> res1 == res2, res2 == res3
>>> res1[:3]
['reloading tkinter\n', 'reloading _tkinter\n', 'reloading warnings\n']
>>> res1 == res2, res2 == res3
(False, False)
>>> set(res1) == set
False
>>> set(res1) == set(res2), set(res2) == set(res3)
(True, True)

but when i enter in for 3.6.1 i got the following instead. Where the code output for >>> res1 == res2, res2 == res3.

Python 3.6.1 (default, Mar 22 2017, 20:49:10)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> res1 = os.popen('~/code/reloadall.py tkinter').readlines()
>>> res2 = os.popen('~/code/reloadall2.py tkinter').readlines()
>>> res3 = os.popen('~/code/reloadall3.py tkinter').readlines()
>>> res1 == res2, res2 == res3
(True, False)
>>> set(res1) == set(res2), set(res2) == set(res3)
(True, True)

Thank you.

Note from the Author or Editor:
[No changes required: informational only]

There's not enough detail to be sure, but it looks like some of the errors you saw may have been caused by the DOS-endlines encoding of the examples distribution package. Unix shells don't generally like these, despite correct #! lines and chmod permissions. Try running the examples through a dos2unix command line (or similar endline conversion technique). Simpler still, just give an explicit Python in the command lines that os.popen() runs; this works fine for me on Mac OS X under Python 3.5 (Ubuntu should be similar):

/.../LP/5E/Examples/lp5e-code-1.0-jun1813/code$ python3
>>> import os
>>> res1 = os.popen('reloadall.py tkinter').readlines() # fails on Unix
/bin/sh: reloadall.py: command not found
>>>
>>> res1 = os.popen('python3 reloadall.py tkinter').readlines()
>>> res2 = os.popen('python3 reloadall2.py tkinter').readlines()
>>> res3 = os.popen('python3 reloadall3.py tkinter').readlines()
>>> res1[:3]
['reloading tkinter\n', 'reloading _tkinter\n', 'reloading re\n']
>>> res1 == res2, res2 == res3
(False, False)
>>> set(res1) == set(res2), set(res2) == set(res3)
(True, True)

As for a difference in output under Python 3.6: I cannot test at the moment, but please verify that your #! lines all use the same Python, or use an explicit "python3" (or "python") per above. It seems more likely that you're comparing different Python's outputs. It's possible that 3.6 tweaked the import machinery in ways that alter reload() results (alas, imports are a perennial target for Python developers), but that's a secondary possibility.

name = 'global'

# del name

def func():
name = 'enclosing'
class Cls:
print(name) # 1st print
name = name # Cls.name attr
print(name) # 2nd print

# running func() outputs:
# 1st print => global
# 2nd print => global
#
# but uncommenting del name
# throws NameError
#
# Isn't name supposed to reference
# 'enclosing' from func's local scope,
# according to LEGB scope lookup protocol?
#
# python --version => 3.10.6
# Operating System => Ubuntu
func()

Note from the Author or Editor:
[No changes required; clarification/supplement only]

For this reply, please visit:

https://learning-python.com/lp5e-class-scope-bug-errata-mar24.html

This reply was relocated there because this errata page doesn't support larger replies, and breaks embedded code so badly that it cannot be read.

The TL;DR version is that this post stumbled onto an obscure bug in Python class scopes that's been known but unfixed open since 2010. The reply illustrates this bug's consequences.

(Future posters: please don't use this page as a chat forum. It's meant only for simple book errata posts, and cannot handle the sort of interaction afforded by other contacts. I'm happy to respond to more substantial queries by email.)

The following sentence: "Factories can be a major undertaking in a strongly typed language such as C++ but are almost trivial to implement in Python" seems to suggest that Python is not strongly typed, which causes confusion because on P149 of the book, you mentioned that Python is strongly typed. Could you clarify this point?

Note from the Author or Editor:
REPRINTS: Please change the "strongly" here to "statically". This is on page 986 in recent printings, near the end of the first paragraph. Specifically, change:
in a strongly typed language
to:
in a statically typed language
This shouldn't impact page breaks.

DISCUSSION: I agree with the poster - there's an important distinction between static and strong typing, as called out earlier in the book (e.g., pages 99/97 and 181/175). Python is strongly typed - it has specific rules about what you can do to each type, but it is not statically typed - it deduces object types dynamically from their creation, instead of program declarations. By contrast, C++ is both strongly and statically typed; it's static type declarations make it difficult to use objects with the same flexibility as in Python.

I suspect that prior editions of this text were not as crisp on the distinction as the current one is, and this is probably a lingering artifact of the earlier looseness. We'll tighten this up in the next reprint.

Addressing the "Looping in __repr__" question, it is mentioned that "you can avoid the loops by using isinstance to compare the type of attribute values against types.MethodType in the standard library, to know which items to skip."

But this does not seem to work. Once you use getattr(self, attr) or its alternative (e.g., eval) to access the attribute values, you trigger __repr__, before doing comparison with types.MethodType or skipping any items. Therefore the loop is not avoided.

Would you mind clarifying this or posting the code for the updated __repr__ overloading?

Note from the Author or Editor:
[No book changes required: informational only]
Sure -- though the code formatting might not come out very well on this page. In short, you must run the type test _before_ the string formatting; getattr() doesn't trigger __repr__ itself, the string formatting does. Here's the __repr_ version without the loop:

# listinherited-reprfix.py (less __main__ code and comments trimmed)
import types
class ListInherited:
"""
Use dir() to collect both instance attrs and names inherited from
its classes; use __repr__, but avoid loops for methods by type testing;
"""
def __attrnames(self):
result = ''
for attr in dir(self):
if attr[:2] == '__' and attr[-2:] == '__':
result += '\t%s\n' % attr
else:
obj = getattr(self, attr)
if isinstance(obj, types.MethodType):
result += '\t%s=<<Method: %s>>\n' % (attr, obj.__name__)
else:
result += '\t%s=%s\n' % (attr, obj)
return result

def __repr__(self):
return '<Instance of %s, address %s:\n%s>' % (
self.__class__.__name__,
id(self),
self.__attrnames())

This works the same as the __str__ based listinherited.py in the book, but doesn't display the class to avoid the loop (displaying additional detail is left as exercise):

c:\code> listinherited.py
<Instance of Sub, address 43359144:
_ListInherited__attrnames=<bound method Sub.__attrnames ...
...__X names trimmed
data1=spam
data2=eggs
data3=42
ham=<bound method Sub.ham of <testmixin.tester.<locals>.Sub ...
spam=<bound method Sub.spam of <testmixin.tester.<locals>.Sub ...
>

c:\code> listinherited-reprfix.py
<Instance of Sub, address 43549640:
_ListInherited__attrnames=<<Method: __attrnames>>
...__X names trimmed
data1=spam
data2=eggs
data3=42
ham=<<Method: ham>>
spam=<<Method: spam>>
>

Folow-ups to lutz@rmi.net.

I wanted to ask just for clarification, if the phrase "Printing a wrapped object directly (...) which then passes the call on to the wrapped object." shouldn't have been "Printing a *wrapper* object directly...". It would help for a better understanding of the "version skew" and the overall delegation behavior. Thank you. C.S.

Note from the Author or Editor:
[No edits required]. I understand the confusion here, and partly agree with this post, but the original wording seems to convey the intent slightly better than the suggested change. A "wrapped" object is indeed a "wrapper" object in memory once it's wrapped, but it's not generally thought of that way. The object has simply been augmented with a wrapper layer, which routes calls back to the original "wrapped" object, which is the true subject of operations. Calling out the "wrapper" object as proposed seems to give it too much prominence in the model. Grey to be sure, but I'd rather leave this as it is. I'm keeping this reply here as a clarification for others.

Assuming we can fit them in without impacting page breaks badly, I'd like to add two footnotes about use of the __dir__ method in dynamic or proxy classes based on __getattr__ or __getattribute__.

This operator overloading method (among others) is not covered in this book for space, but there are two ideal places to add a mention, plus a pointer to additional coverage in the latest Python Pocket Reference.

THE CHANGES:

1) On Page 977, add a footnote reference at the end of the first paragraph on this page:
"""
...ethereal at best!*
"''"

which refers to the following new footnote text:
"""
* Some dynamic and proxy objects based on __getattr__and the like can also use the __dir__ operator overloading method to manually publish an attributes list for dir calls. Because this is optional, though, general tools cannot rely on their client classes to do so. See other resources such as Python Pocket Reference, 5th Edition for more on the __dir__ method.
''""

in which __dir__, __getattr__, and dir are literal font, and the book title is italics and possibly a link (this is the end of chapter, so it's okay if this changes the last page break, but if this adds a page, we can shorten or drop the last sentence of the insert, or simply cut its "other resources such as" part if sufficient).

2) On Page 1235, add a footnote reference to the end of the first sentence in the last paragraph:
"""
...names do not appear in dir results.*
"""

which refers to this new footnote text:
"""
* As noted in Chapter 31, such dynamic classes can also use a __dir__ method to provide an attribute result list for dir calls, though general tools cannot depend on this optional interface.
""""

in which __dir__ and dir are literal font (this page appears to have enough space, but again, let me know if it changes paging substantially).

In this section, the author is demonstrating that a class is a callable object. In the last step of the sample code, we create a dict of callables keyed by their result, including a Negate instance and the class itself. Then we iterate through the key, value pairs of the dict, printing result strings using the str format method: print('{0:2} => {1}'.format(key, value))

However, on the line above, the Negate instance throws the following exception: "TypeError unsupported format string passed to Negate.__format__". As per https://docs.python.org/3/reference/datamodel.html, presumably this is because the interpretation of the format_spec argument is up to the type implementing __format__(),

In order to format Negate, overload Negate.__format__ as follows to delegate to the __format__ method of self.val's type:

def __format__(self, spec):
return self.val.__format__(spec)

Note from the Author or Editor:
[No changes required - informational only] This example works as shown, but the language tools it relies on have unfortunately changed -- and multiple times -- in Python 3.X since this book was published, and it's impossible to cover these changes in the book at this point. Per testing:

1) This example works correctly, without error, and as shown in the book in both Python 3.3 and 2.7, the versions current at publication and explicitly noted as covered by the text. In both of these Pythons, the Negate class's output line is as the book lists it: "-5 => <class '__main__.Negate'>" .

2) In Python 3.5, though, the formatted Negate class generates an exception, with text: "TypeError: non-empty format string passed to object.__format__". 3.4 was unavailable for testing, but Python changes broke this code by 3.5.

3) Worse, in Pythons 3.6 and 3.7, the Negate class formatting also fails, but with different exception text that is the same as that reported by this post: "TypeError unsupported format string passed to Negate.__format__".

In other words, the format() method's machinery has been the scene of multiple thrashings since the book was published. It changed some time around Python 3.5, and then again in 3.6, and both changes left the book example broken for users of these Pythons. This is just one minor example in a large book, but it's less than ideal when unchanged code breaks -- twice.

There's not much that the book can do about this today, but I'm retaining this reply for other readers who may encounter this in recent Python releases. Given Python's constant and rapid rate of change, readers should expect to consult Python's latest docs, especially its What's New, for recent Python gyrations -- exactly as this poster did.

[Changed to clarification given the context; this is on page 953 in earlier printings.]

For the following code on Page 1013

for attr in list(getattr(X, '__dict__', [])) + getattr(X, '__slots__', []):
print(attr, '=>', getattr(X, attr))

If the instant object doesn't assign some names defined in the __slots__ sequence, the above code would return an AttributeError, for example, running the above code in the following case would cause X.b to fail:
class D(object):
__slots__ = ['a', 'b', '__dict__']
X = D()
X.a, X.c = 1, 3

Maybe provide a default value for getattr() to make the code a little more robust:

for attr in list(getattr(X, '__dict__', [])) + getattr(X, '__slots__', []):
print(attr, '=>', getattr(X, attr, 'NOT ASSIGNED'))

Thank you!

Note from the Author or Editor:
[No edits required]. You're right that the code would fail if 'X.b' is not assigned, but that's intentionally illustrated earlier in the session by the failing 'X.a' fetch, and 'X.b' is assigned before this code is run to avoid the error.

Really, the point of this example is to demo some of the strange boundary cases of slots - one of which you uncovered. It's also true that the code would be more robust with a getattr() default as you noted, but this is supposed to show slot oddities like this, not be production-grade code. So, I'd rather not change this specific example, but I'll keep this post for any others who may stumble onto the surprise.

Assuming we can fit it in without impacting page breaks badly, I wish to add a note clarifying how super() and inheritance relate. The short story is that they don't: super() precludes normal full inheritance, and instead performs a custom scan. There's more on this in the latest Python Pocket Reference (along with other fine points omitted from LP5E for space), but a few words may help here too.

THE CHANGES:

1) On Page 1064, just before header "Class Gotchas", add a new Note box with the following text (in which "super" is literal font, "Chapter 40" is a link, and "--" is a single dash character; this will shift some page breaks, but it's near the end of chapter, and the breaks from here to chapter end are arbitrary; let me know if it adds a page):

"""
Also watch for Chapter 40's formal description of full inheritance -- a procedure which super objects eschew for a custom scan of a context-specific MRO tail, looking for the first appearance of an attribute (descriptor or value) along the way. Full inheritance is used on the super object itself only if this scan fails. The net effect is a special case for basic name resolution, imposed on both the language and your code for the sake of a relatively rare use case.
"""

2) On Page 1386, at the end of paragraph 2, change the sentence just before header "Assignment inheritance" that reads:
"""
See Chapter 38 for more on these tools and descriptors.
"""
to the following, adding just the clause at the end, in which "super" is literal font, and "Chapter 32" is a link:
"""
See Chapter 38 for more on these tools and descriptors, and Chapter 32 for the super
special-case MRO scan.
"""
I'm hoping this doesn't add a line and change page breaks; let me know if it does,

The code listing sets the __str__ attribute of Sub to Lister.__str__. Setting it to ListTree.__str__ would be more clear, as the current listing implies that the lister module from Chapter 31 has been imported; but no such assumption is required if we simply reference ListTree.__str__.

Note from the Author or Editor:
This code assumes the lister.py collector/selector module back on page 1006, but I agree that it's a bit of a stretch given the lack of an explicit reference or import here (probably, this example code was nearer to the required import originally).

[EDIT 1] Let's change the "Lister.__str__" here to "ListTree.__str__" as proposed, but we also then need to change it in the "#" comment to the right. The updated code line should be this, making sure its "#" aligns with that of the preceding line as before:

__str__ = ListTree.__str__ # Explicitly pick ListTree.__str__

[EDIT 2] Also, while researching this report, a related typo turned up. On page 995, paragraph -2, please change the "ListerInstance" to "ListInstance". (I don't know the history on this one either, but it's probably just one too many listers to keep straight.)

In hindsight, the book isn't as crisp as it might be on default Unicode encodings. This is a subtle issue that varies per platform and Python line, and is impossible to cover in full now; but the following 6 minor patches will improve the existing material, and shouldn't change page breaks much (please let me know if they do, and run the edits past me for review):

1) ON PAGE 1206, near the end of the third bullet item
--change--
(e.g., ASCII, or UTF-8 on Windows in the U.S.—sys.getdefaultencoding gives your default if you care to check),
--to--
(e.g., ASCII, UTF-8, or Latin-1—locale.getpreferredencoding(False) gives your open default if you care to check),
--where--
The "locale.get...(False)" part and "open" are literal font.
This is on page 1166 in older printings.

2) ON PAGE 1217, the entire last paragraph
--change--
These encode and decode methods (as well as file objects, described in the next section) use either a default encoding for your platform or an explicitly passed-in encoding name. For example, in Python 3.X:
--to--
Both these encode and decode methods and the file open calls we'll explore ahead use either an explicitly passed-in encoding name or a default. In Python 3.X, the methods' default is always UTF-8, but open uses a value in the locale module that may vary per platform. In 2.X both defaults are usually ASCII, as exposed in the sys module (which allows changes at start-up). For example, in 3.X:
--where--
All "encode", "decode", "open", "locale", and "sys" are literal font.
This may add a page break; to localize the change, either let the paragraph run over to the next page, or move just its last sentence to the next page.
This is on page 1177 in older printings.

3) ON PAGE 1218, paragraph 1, sentence 2
--change--
First of all, your platform’s default encoding is available in the sys module,
--to--
First of all, your platform’s various default encodings are available in the sys and locale modules,
--where--
The "sys" and "locale" are literal font.
This is on page 1177 in older printings.

4) ON PAGE 1218, second code listing, lines 1 through 5
--change--
>>> import sys
>>> sys.platform # Underlying platform
'win32'
>>> sys.getdefaultencoding() # Default encoding for str here
'utf-8'
--to--
>>> import sys, locale # Windows open() uses cp1252 (Latin-1)
>>> sys.platform # but str() never uses a default...
'win32'
>>> locale.getpreferredencoding(False), sys.getdefaultencoding()
('cp1252', 'utf-8')
--where--
All the original's font style and "#" vertical alignment is retained.
This is on page 1178 in older printings.

5) ON PAGE 1243, in the first sentence at the top of page
--change--
(and UTF-8 is Python 3.X’s default encoding):
--to--
(and Latin-1, a.k.a. cp1252, is Python 3.X’s default open encoding on Windows per locale.getpreferredencoding):
--where--
The "open" and the "locale.get..." part are literal font.
This is on page 1202 in older printings.

6) ON PAGE 1243, first code listing, lines 2 through 4
--change--
>>> import sys
>>> sys.getdefaultencoding()
'utf-8'
--to--
>>> import sys, locale
>>> locale.getpreferredencoding(False)
'cp1252'
--where--
All the original's font style is retained.
This is on page 1202 in older printings.

[Discussion only follows]
Looking over the output of the code on page 1243, the UTF-8 result of sys.getdefaultencoding() is clearly not used for open() on Windows. In the second code listing, the default encoding's result differs from an explicit UTF-8, and applies Latin-1 (a.k.a. cp1252) instead. The sys module does host some Unicode defaults, but the open() default must reside elsewhere.

This is a complex issue that varies per platform and Python line. In brief: per its recent docs, Python 3.X now uses the locale.getpreferredencoding(False) result's "guess" for the open() default. It seems to have meant to remove 2.X's sys.getdefaultencoding() but never did, leaving the matter tersely documented and confused. In 3.X, the sys module's setting still reflects the encoding methods' default, but open() doesn't use it; 2.X's policies vary, and include an odd removal of sys.setdefaultencoding() after startup.

This book obviously doesn't have space to cover this with full precision today; locales are a substantial topic alone, and the "guess" term in recent 3.X docs seems murky at best (and cautionary at worst; a code excursion seems required). But as a partial fix, the edits described can at least clarify the issue.

Of course, you should use explicit Unicode encoding names whenever possible and not rely on defaults that may vary per Python, platform, and machine. If you work across multiple platforms, using 3.X's open() defaults means that you'll have to remember where each file was last saved to reopen it correctly. Still, it's useful to know what those defaults may be, especially if you work in a single Unicode context.

Also note that the edits deal mainly with Python 3.X; users of Python 2.X's similar codecs.open() should consult 2.X manuals for more details (which, unfortunately, appear more terse than 3.X's!).

Two Unicode-encoding edits for clarity:

1) On page 1218, at the end of line 1 in the second code listing, change:
>>> import sys, locale # Windows open() uses cp1252 (Latin-1)
to:
>>> import sys, locale # Windows open() uses cp1252 (a Latin-1 superset)
retaining the original "#" alignment.

2) On page 1243, in the first line on the page, change:
(or Latin-1, a.k.a. cp1252,
to:
(or Latin-1's cp1252 superset,

[Discussion: this may seem trivial, but the CP-1252/Latin-1 distinction is a fairly big deal; they're not the same, and treating them as such can lead to display issues (or worse). For a prime example, see:

learning-python.com/post-release-updates.html#showcodeunicode

In brief, CP-1252 has extra characters (or different characters, depending on the Latin-1 definition) which may be botched if treated as Latin-1. A slanted quote, for example, exists in CP-1252's character set, but not Latin-1's (its encoded byte may decode to an obscure control code in Latin-1). Many tools treat Latin-1 as CP-1252, since the latter is generally a superset of the former. But their decoded text may differ in your programs.]

Three source-encoding edits for clarity:

1) On page 1228, middle of 3rd paragraph, --change--:
, Python uses the UTF-8 encoding by default, but it allows you to change this to support arbitrary character sets by including a comment that names your desired encoding. The comment must be of this form and must
--to--:
, Python uses UTF-8 in 3.X (and ASCII in 2.X) as its default encoding, but allows you to use arbitrary encodings and the character sets they support by including a comment that names your desired encoding. The comment is usually of this form and must

2) On page 1229, line 1 of 2nd paragraph, --change--:
fall back on the standard UTF-8 encoding,
--to--:
fall back on the default source encodings,

3) On page 1224, near end of first paragraph on page, --change--:
which, as discussed later, defaults to UTF-8 unless an encoding
declaration is given
--to--:
which, as discussed later, defaults to UTF-8 in 3.X (and ASCII in 2.X)
unless an encoding declaration is given

Some of these will probably change page breaks: please run past me if so.

[Discussion: as originally written, this section has two shortcomings: it did not note 2.X's different source-encoding default, and was too rigid on encoding comment format (Python actually accepts a few forms, though the one shown is by far most common). The 2.X default matters if you're writing code that must work on either line (see many ISPs). Edit #3 isn't required per se, given that it's in a 3.X code section, but it's best to restate the difference.]

return lambda *args: '[Getattr str]'

It seems that "*args" here is unnecessary under all circumstances because object.__str__(self) expect 0 arguments.

Note from the Author or Editor:
No -- I'm not going to mark this as an errata, because the goal here was to simply flag interceptions of attribute fetches for built-in operations, not to provide full implementations for the intercepted operations. Hence, the intentional coding of a generic "any argument list goes" function with a *args is fine; it simply catches the call so as to produce an indicator message. This was also coded for symmetry with the result for other operations, whose arguments do vary.

That being said, this underscore an interesting point. The "*args" is indeed optional in this lambda, but for reasons more subtle than the post may have meant to imply. A __str__ implementation run by some prints should normally allow for at least the automatic "self" argument:

>>> help(object.__str__) # in 3.X
Help on wrapper_descriptor:

__str__(...)
x.__str__() <==> str(x)

>>> object.__str__()
TypeError: descriptor '__str__' of 'object' object needs an argument

Importantly, in this book example, __getattr__ is intercepting the attribute *fetch*, not the later operation *call*. By contrast, the explicitly coded __len__ in this class catches the operation call, not the attribute fetch. That is, the book example deliberately handles this step only:

>>> object.__str__
<slot wrapper '__str__' of 'object' objects>

In general, though, a program that really intends to implement __str__ in full should usually return a *bound method* object that retains the "self" available at attribute fetch time, and not a simple function created by a lambda. When Python later calls the fetch's result, it omits the original "self" from the arguments list, assuming it to be part of and provided by a bound method (or other state retention device) if needed by the operation implementation. Thus, no self argument is required of or passed to a simple function fetch result.

Python normally creates bound methods automatically on attribute fetch, when one is coded explicitly as a method with a self argument (like the class's __len__), or fetched from a proxied object (by calling the built-in getattr(wrapped, attrname), the normal coding pattern in delegation contexts). By using a lambda in the example, we're implying that the later operation call won't require the self object that was present at attribute fetch time; this simple call tracer does not.

Again, though, illustrating all this was well beyond the goals of this particular code. Its liberal method coding suffices as a catch-all demo of attribute fetch interception in __getttr__ and __getattribute__ -- and the lack thereof for built-in implicit fetches in new-style classes. See Chapter 31 for more on bound methods in general.

An expansion for clarity on decorator tradeoffs. On Page 1311, change the entire second last paragraph from:
"""
Decorators also promote code encapsulation to reduce redundancy and minimize future maintenance effort; although other code structuring tools do too, decorators add explicit structure that makes this natural for augmentation tasks.
"""
to this:
"""
Decorators also promote code encapsulation to reduce redundancy and minimize future maintenance effort; augmentation code appears just once in the decorator callable, instead of being copied for each deployment. Although manager functions can achieve this too, decorators also offer an explicit syntax and seamless call model that makes them natural for augmentation tasks.
"""
This should add 2 lines, there seems to be room on the page, but please contact me if this changes page breaks.

Quotation marks missing.

timeit.timeit(number=1, stmt=lambda: listcomp(1000000))

should be

timeit.timeit(number=1, stmt='lambda: listcomp(1000000)')

or

timeit.timeit(number=1, stmt="lambda: listcomp(1000000)")

Note from the Author or Editor:
No. As stated by the book on page 665 (in Chapter 21's coverage referenced by this example), the Python timeit module accepts either a string object or a no-argument callable object for its "stmt" argument. In the example, the lambda simply defers execution the same as using a string. See Chapter21 and the Python manual for more info:

https://docs.python.org/3/library/timeit.html#timeit.Timer

No changes required, retained for other readers.

The comment on the Sub class incorrectly states "Classes inherit from superclasses but not from metaclasses." In fact, classes do inherit from metaclasses; it's instances that don't.

Note from the Author or Editor:
This comment merits an edit, but it's not incorrect for the section in which it appears. In short, "inheritance" has a specific usage near this comment, where it applies to instance/class search only, not class/metaclass. Because this term is also used more generally later, though, it's worth an edit to minimize confusion.

[EDIT] Please extend the comment on this page from the first of the following to the second:

# But not from metaclasses
# But not from metaclasses for instance access

Also, an unrelated formatting issue: a bit further down on this page, the "r" at the end of the following comment is formatted oddly -- please fix:

# Inherited from Super

[DISCUSSION] As described in depth by the narrative and code around this comment, it's true that classes obtain attributes from metaclasses when accessed directly, but not when the reference originates at an instance. In fact, this is one of the primary points of this section.

More profoundly and subtly, though, the section of the book containing this comment deliberately uses terminology to draw a pseudo-mathematical distinction between the two (nearly) orthogonal attribute-tree searches in new-style classes:

- "Inheritance" refers to the normal instance/class relationship
- "Instance" refers to the special class/metaclass relationship

This usage of these two terms is noted explicitly earlier in this chapter, in the paragraph that begins "Notice that" on page 1413. The former applies to attribute searches started at an instance, and the latter is an extra step for attribute searches begun at a class only. (Technically, class-level accesses first search the superclass tree also searched last for instances, which is why the two lookups are not quite orthogonal.) In addition, this section uses the term "acquired" to distinguish names obtained from the "instance" tree.

In this intended sense, the book's adjacent comments are accurate, because "inheritance" has been reserved for the instance/class tree lookup only:

# Classes inherit from superclasses
# But not from metaclasses

Admittedly, though, this grows potentially confusing when later sections of this chapter generalize the term "inheritance" to refer to attribute lookup in both class and metaclass trees (and show that the only real difference is the extra step into the metaclass tree for class-based fetches). Hence, augmenting the comment as described reduces possible later confusion, even though the comment is not incorrect for the context in which it appears.