There are place where I use monocode font to show the value of a string without including the quotation marks. Luciano suggests we avoid that and I agree.

For example, if we have a line of code like this:

s = 'abc'

And we refer to the string in the text, it should be 'abc', not abc.

On the next pass, let's keep an eye out for them.

Currently the cross references in the Jupyter notebooks are just Chapter xxx or Section xxx.

Is there a way for me to do cross references in the Jupyter notebooks, so they get built correctly on Atlas?

Or will we fill these in later in the production process?

The chapter 1 link "If you are not familiar with Jupyter notebooks, click here for a short introduction." shows the error:

Notebook not found

There was an error loading this notebook. Ensure that the file is accessible and try again.

Ensure that you have permission to view this notebook in GitHub and authorize Colaboratory to use the GitHub API.
https://github.com/AllenDowney/ThinkPython/blob/v3/chapters/jupyter_intro.ipynb

Could not find jupyter_intro.ipynb in https://api.github.com/repos/AllenDowney/ThinkPython/contents/chapters?per_page=100&ref=v3
wb@https://ssl.gstatic.com/colaboratory-static/common/3e1e9f5191f3657451c6f18bfa55805d/external_polymer_binary.js:93:517
zL@https://ssl.gstatic.com/colaboratory-static/common/3e1e9f5191f3657451c6f18bfa55805d/external_polymer_binary.js:2351:68
FLa/<@https://ssl.gstatic.com/colaboratory-static/common/3e1e9f5191f3657451c6f18bfa55805d/external_polymer_binary.js:2338:442
wa@https://ssl.gstatic.com/colaboratory-static/common/3e1e9f5191f3657451c6f18bfa55805d/external_polymer_binary.js:16:57
ua.prototype.next_@https://ssl.gstatic.com/colaboratory-static/common/3e1e9f5191f3657451c6f18bfa55805d/external_polymer_binary.js:14:195
laa/this.next@https://ssl.gstatic.com/colaboratory-static/common/3e1e9f5191f3657451c6f18bfa55805d/external_polymer_binary.js:17:48
b@https://ssl.gstatic.com/colaboratory-static/common/3e1e9f5191f3657451c6f18bfa55805d/external_polymer_binary.js:17:309

"Many dictionary methods, like keys and items, also work with database objects. So does
iteration with a for statement."

example code from book...

import anydbm
db = anydbm.open('captions.db', 'c')
db['cleese.png'] = 'Photo of John Cleese doing a silly walk.'
for key in db:
print key

running this code on my computer, the following error was thrown.

Traceback (most recent call last):
File "", line 1, in
TypeError: 'dbm.dbm' object is not iterable

Therefore, iteration with a for statement does not work on database objects as described above.

1. In the functions chapter, the exercise where we write the rectangle function, the question repeats part of the previous exercise on pyramid function and the visual representation for the case is also not correct. it is 5 * 5, meant to be 5 * 4

2. In the classes and functions chapter, the exercise on writing is_after function, the case statement is True, True , False and should be True,False,True.

3. In chapter 3, one of the stack diagrams has the bounding box

I noticed today when I tried to import the Structshape module from chapter 12.8 that it was erroring out. It turned out to be the Python 2 syntax for the Print statements, and when updated to Python 3 everything worked flawlessly.

I did a quick search through the repository and found there's quite a few of these still left. I wasn't sure if this was deliberate but on page 2 of ThinkPython there is the following line:

This book is written for Python 3, but I include some notes about Python 2.

It's possible that some beginners may get confused about why the provided examples aren't working.

I've attached the results of my search with the filename and line number in a text file (hopefully removed all the false positives from the comments where print is mentioned):
Python 2 print statements.txt

On a side note - I'm absolutely loving the book (especially the exercises) and really appreciate that this is available as a free resource.

The words.txt file contains racial slurs and other inappropriate words (for example, the n word). It should be updated with the offensive content removed.

Code examples and outputs should be visually distinctive.

Code should be syntax highlighted/colored. Outputs should not.

Inputs and outputs should not include IPython-style labels, like In [17]: and Out [17]:

• The numbers are not useful
• The labels look too much like Python syntax, so they visually complicate the examples

Once the design is settled, I'll need to add a sentence in Chapter 1 to orient the reader (print only).

We should also check the info in the tracebacks, like the one on page 46, to make sure it's consistent (or we explain why not).

In line 4796, two different styles were used to display almost the same thing:
blah blah \verb"'dx is 3'" blah blah {\tt 'dy is 4'} blah

They have different displaying effects. Why they are used in this way?

Check chapter 4: do I need to generate different SVG?