Errata

In the Example 31-13. listtree.py,
In the comments, the statement "-Supports classes with slots: lack of slots here ensures a __dict__". I figured the author meant to say "Supports classes without slots: ..." as classes with slots will not have __dict__.

Also in the definition of the method __attrnames
def __attrnames(self,obj, indent, unders=True):...
The "obj" argument actually plays the same role as "self". Is it redundant? Removing obj and replace it with self in the program yield the same output.

Finally, in the def __listclass(self, aClass, indent):...
there a for loop
for super in aClass.__bases__:...
"super" is a built-in function name, shall we in general avoid naming a variable with a built-in names?

Note from the Author or Editor:
Thanks for your post. It raises 3 issues:

1) No, the comment about slots is correct as is. Mixing in the ListTree class to any other will ensure that a __dict__ attribute is present in the instance. This is even true if it's mixed in to a class with __slots__: __slots__ normally precludes a __dict__, but ListTree (or any of the other lister classes) will ensure that one is added to the mix. See the coverage of slots ahead in this chapter and in Chapter 32.

2) No, the __attrnames() method is correct as is. Notice that this method is called in two places: to get the instance's names, and to get a class's names. "self" may seem redundant in the former, but "obj" and "self" differ in the latter, with "obj" being the subject class. This class will not work with the mod you suggested; please review its code again.

3) Yes, not a bug but potentially confusing, so we changed all "super" to "Super" in this example prior to release so they are distinct from the built-in.

In chapter 32 "Class Odds and Ends" section "And one object rule them all" 2nd paragraph, there is a statement "to avoid combustion, keep in mind that isinstance is true for either a subclass relationship or creation source, though the latter may also imply inheritance through the secondary type-class tree for classes."

It is confusing that function isinstance will return True for a subclass relationship.
For instance, if class A is a subclass of class B, isinstance(A, B) will return False rather than True.
i.e.,
>>>class B: pass
>>>class A(B): pass
>>>isinstance(A, B)
False

Note from the Author or Editor:
Thanks for your post. We tightened this up before the book was released to make it clearer that the isinstance test is based on inheritance through the secondary type-class tree for classes. The primary class tree in your example doesn't apply in this case.

On 6th edition, online early release version.
Chapter 38, Managed Attributes. Why Manage Attributes,
under section "Inserting Code to Run on Attribute Access".
Paragraph 3rd, 4 th bullet "The __get__ and __set__ descriptor methods, for handling access to a specific method and the basis for other tools such as properties and slots
"
Is "...handling access to a specific method..." supposed to be "... handling access to a specific attribute..."?

Note from the Author or Editor:
Thank for your post; for consistency, we changed this as suggested before the book was released.

In the code:
if traceMe: print(f'[{' '.join(map(str, args))}]')

In the print statement, two pairs of single quotes are used instead of nested double and single quotes. It causes error.

Note from the Author or Editor:
This is not an error: it uses Python 3.12+ f-string syntax documented earlier in Chapter 7 (page 164). In short, 3.12 and later allow nested quotes of the same type used for the enclosing f-string, which is a very useful feature demoed by the book intentionally. Because this syntax has already generated two errata posts, though, we added the comment "# Python 3.12+ f-string" to this line to call this out for readers using older Pythons.

The author claims that "Special case: built-in modules like sys, coded in C and statically linked into Python, are always checked first before scanning the module search path."

I am running Python 3.11.
I am wondering if the special cases also include module like "os" that is not on the list of sys.builtin_module_names. os.__file__ indicates it is located in a Python folder listed as the 3rd directory in the sys.path. However, even if I make my own os.py in the current directory, the "import os" statement will still import the builtin os (repr(os) gives "<module 'os' (frozen)>"), i.e., it will not be masked by the user defined one in the current directory.

Note from the Author or Editor:
You're right: "os" cannot be redefined today even though it is not in sys.builtin_module_names. This is because it inhabits an additional and poorly documented "frozen" module set that, along with true built-ins, also takes precedence over sys.path search.

The book's coverage of the module search path focuses on what most programmers need to know and follows that in Python's own docs here:
https://docs.python.org/3/tutorial/modules.html#the-module-search-path

But "os" belongs to an additional category known as "frozens" that is similarly searched first as a special case. This category was added recently in Python 3.11 as a startup optimization, and is part of the version-specific and frequently morphing tale of module imports in 3.X. Given that the need to override something like "os" is very rare, most Python users don't need to care.

To reduce confusion, though, before release we added a brief mention of the frozen category and its "os" member to the book's module-search description, alongside that of true built-ins in the opening of this section. This section now begins:

"""
Special case: built-in modules like sys, coded in C and statically linked into Python, as well as frozen modules like os, optimized for faster startup as of Python 3.11, are always checked first before scanning the module search path and hence take precedence.
"""

Those who do need to care can find the rest of this story in Python's change logs and docs at python.org, which arguably could use some polishing. Some people were also burned by the "frozen" optimization in broken debuggers, so this 3.11 mod clearly merits a callout.

10th paragraph, "And a basic except can catch a group as a collective and process it manually, but an except* cannot catch a group because it would be ambiguous (a schism of the sort that’s usually a hallmark of an ad hoc extension):"

Not sure why except* cannot catch a group,
the code below this paragraph:
"try:
... raise ExceptionGroup('Lots', [IndexError(), SyntaxError()])
except Exception as E:
...
"
yield the the exact same results if changing "except" to "except*".

Note from the Author or Editor:
This is at the top of page 925 in PDF and print. Please change the third line of the first code block on this page from the first of the following to the second:

except Exception as E:
except ExceptionGroup as E:

Discussion: the poster is right that except and except* work the same if Exception is used, but this is referring to catching a group explicitly--something that works in except but is a runtime error with except*. See PEP 654's "Forbidden Combinations" for more details; it's one of a handful of things described there that make the two exception models incompatible. Regrettably, the example demoing this wasn't as tight as it might have been. The reprints mod above should help clarify.

System: Windows 11 Home version 24H2
Python version 3.14.0

book example:
$ python3
>>> import converters
>>> scan = converters.Uppercase(open('trihack.txt'), open('trihackup.txt', 'w'))
>>> scan.process()

At my system this will only create and open the new trihackup.txt file. There is nothing writen to it. If the code '.process()' in the last line is placed behind the code in the line above it the code runs fine:

$ python3
>>> import converters
>>> scan = converters.Uppercase(open('trihack.txt'), open('trihackup.txt', 'w')).process()
>>> scan

Note from the Author or Editor:
[Edits: not a bug, but to avoid similar confusion, please expand the sentence on page 785 paragraph 2 from the first of the following to the second, which shouldn't add a line break:
"Here, we use an output file instead of a stream:"
"Here, we use an output file instead of a stream (be sure to exit your REPL to finalize the file):"]

This example works as shown in the book, but your post raises an interesting point. Your mod isn't obviously different: it simply runs process() on the Uppercase object immediately instead of on the next line, and the Uppercase object retains references to the passed in file objects either way (via the Processor superclass's reader/writer attributes).

Subtly, though, the embedded file objects won't be garbage collected—and hence automatically flushed and closed—until there are no more references to them. The book's version retains a reference in the "scan" variable, but your mod does not: your "scan" is None, the result of calling process(). Hence, your version triggers file flush and close just by losing references to the files, and this finalizes file content. Some REPLs might hold onto file objects even longer, subverting both versions and differing from normal script execution.

All of this is covered by the book on page 215, and mentioned again on pages 223, 908, 973, and 776 (search for "auto-close" in e-media). In this particular example, the book echoes the file in a system shell, which implies that the Python REPL was exited. However, if you suspend the REPL instead of closing it (e.g., with ctrl-Z on Unix) or inspect the file in another window, the output file may not yet be complete.

As suggested in the book, if you really want to avoid incomplete files like this before REPL exit, you must explicitly close the files with code like this:

$ python3
>>> import converters
>>> infile = open('trihack.txt')
>>> outfile = open('trihackup.txt', 'w')
>>> scan = converters.Uppercase(infile, outfile)
>>> scan.process()
>>> infile.close()
>>> outfile.close()
>>> (ctrl-Z)
[1]+ Stopped

$ cat trihackup.txt
HACK
HACK
HACK!

As you can see, this requires substantially more code: 7 lines versus 3, sans compression coding tricks. Which is why it's not always spelled out this way in the book for simpler REPL examples like this one.

The variable name a_Long_name uses mixed casing and underscores.

The variable names should use lowercase letters with words separated by underscores (snake_case).

# Incorrect:
a_Long_name

# Correct:
a_long_name

Note from the Author or Editor:
Please change "a_Long_name" to "a_long_name" in paragraph -3 of page 279.

[Discussion] No, this is not a mistake in Python, it's the poster's stylistic preference and seems to be picking nits too much. There is nothing at all wrong with using "a_Long_name" for a variable, either syntactically or stylistically. In fact, it's arguably useful to show that this works as is.

That said, since this was called out, it feels slightly better to go with either all lower or upper case here just to make the name jive with the "aLongName" camel-case version preceding it. But again, it's not a mistake, and please don't post opinions as such; category changed.