Programming Python, Third Edition
by Mark Lutz

The unconfirmed error reports are from readers.  They have not yet been 
approved or disproved by the author or editor and represent solely the
opinion of the reader.

Here's a key to the markup:
        [page-number]: serious technical mistake
        {page-number}: minor technical mistake
        <page-number>: important language/formatting problem
        (page-number): language change or minor formatting problem
        ?page-number?: reader question or request for clarification

This page was updated June 4, 2008.


UNCONFIRMED  errors and comments from readers: 


(5)  paragraph 2;
The original wording in this pararaph was mangled somewhere during the 
edit process. The sentence:

"And although Python is _dynamically_ typed -- types are tracked automatically
instead of being declared (it is still _strongly_ typed) -- every operation 
is sanity checked as your program runs."

was originally written as

"And although Python is _dynamically_ typed -- types are tracked automatically
instead of being declared, it is still _strongly_ typed -- every operation 
is sanity checked as your program runs."

The modified version works in a way, but is difficult to parse, and subtly 
different enough from its original intent to be broken.


(38) Example 2-2;
In example 2-2, the source file is named make_db_files.py. However, thereafter it is referred to as make_db_file.py. (without the 's')


(42) Example 2-7;
In the title of Example 2-7 the file is called "update-db-pickle.py" however, it is referenced as "update_db_pickle.py" (using '_' instead of '-')thereafter.


(48)  Paragraph on encapsulation;
"...without breaking their users."

I think the last word in the paragraph was meant to be "uses" not "users".



{63}  Example 2-27;
In customizegui.py, the "from Tkinter import *" line at the very top of this 
example is missing in the book (the result of an unfortunate cut and paste, 
apparently). Without it, the "mainloop()" call at the end is undefined. This 
was fixed in the examples distribution package (version 1.1), but not in the 
book.


(74) Example 2-32 -- webserver.py;
The coding of the webserver example tripped me up. I couldn't get the webserver to run. It would either crash with a "permission denied" error, or "address in use" error when run as root.

A more experience user pointed out that port 80 is reserved so no user but root could run the thing, and that apparently some process was already running on that port. The workaround was to change the port to 8080 (or somesuch, anything over 1023) and to modify the url to localhost:8080 (or whatever). This worked fine and I'm back to work.

I'd suggest a footnote identifying the issue and providing a workaround.


[107] 3rd paragraph;
the statement:

os.sep.split(dirpath)

must be replaced by:

dirpath.split(os.sep)


{116}  1/4 up from bottom;
     C:\temp>cd C:\PP2ndEd\examples
Should be:
     C:\temp>cd C:\PP3rdEd\examples



(128)  Middle of page;
C:\...\PP3E\System\Streams>python sorter.py < data.txt     sum file
1164

should be:

C:\...\PP3E\System\Streams>python adder.py < data.txt     sum file
1164



{157} first block of code;
The script opens a file named 'data.txt', yet the description immediately following the code references the file 'hillbillies.txt'. The example file is in fact 'hillbillies.txt'; the script as provided does not work unless the file data.txt happens to exist in the same drive as 'hillbillies.txt'.


{203}  Last example;
(Tiny comment, but the text might confuse people new to Linux.)

The example uses

$ echo $status

to query the status code and write that this is the way to do it "on Linux". 
In fact, it is the way to do in in the C shell family of command language 
interpreters. My Linux distribution defaults to the GNU Bourne-Again Shell 
(bash) where you query the question-mark variable:

$ python -c 'import sys; sys.exit(42)'
$ echo $?
42

(If you ever wondered where perl got most of its "line noise syntax" from, 
wonder no more.)

The valuable "status" is typically not defined. Once upon a time there was 
only the Bourne Shell on *nix machines and this behaviour is found in all 
command language interpreters derived from it.

I suggest changing the last text paragraph from
"On Linux, for example, ..."
to
"On Linux using the C shell, for example, ..."

If you want to be careful, add a footnote about the Bourne shell family 
(sh, ksh, bash).



(231)  4th line from bottom [line 36 of launchmodes.py];
The launchmodes.py program fails in some modes when python is installed in a
directory containing a space, e.g.,

C:\Program Files\Python24

The System and Popen classes must quote the python executable's full pathname 
when building command strings that use it on the Windows platform.

For instance, the

System('Pyedit', program)()

call in selftest() fails with an error message to the effect that it cannot 
find the executable "C:\Program".

Changing the format string in line 36 of launchmodes.py from

'%s %s'
to
'"%s" %s'

fixes the problem on my Windows platform. But it will probably break it 
under Unix.

A similar problem affects the Popen class. However, it just fails to 
launch PyEdit silently in selftest.

A portable fix would probably require tweaking findPythonExe to quote 
(or escape blanks in) the return value if it contains blanks in a platform 
dependent manner.



{239}  Example session in middle of page;
The example session is purportedly run on a Windows machine, but the 'ls' 
command is not available on Windows.



{242}  Example session in middle of page;
Again, in this example, which is purportedly run on Windows, the 'ls' 
command is used, which is not available on Windows.



{245-247}  Sample outputs;
Repeated use of 'ls' command in purported Windows sessions.
This is a Unix command, not available from a DOS prompt in a standard Windows
environment.


{309}  Footnote *;
I found the references to  find.find  in the footnote and on the following page
confusing. On my platform (Linux), PP3E/PyTools/fixeoln_all.py does not use
find.find  but instead calls the shell's  find(1)  function.

Trying to follow the instructions in the footnote, I naively tried an

import find

which failed because I wan't in the PyTools directory.  Instead I used

from PP3E.PyTools import find

which worked like a charm. I must have mentally blocked out all the Dos 
specific code fragments in my reading of the examples.

Suggestion: Using the external command in example 7-4 probably doesn't add 
much over the examples we have already had, so why not use your PP3E.PyTools 
version? That would make the footnote and the discussion on 'Rewriting with 
os.path.walk' easier for us "Unix ghetto dwellers" to follow.

(And of course you could re-rewrite it to os.walk instead, but then you'd 
lose a huge footnote on page 311.)



{339}  Example 7-24 and others;
The example in the book is actually fine, but the file distributed from the 
web site still has

from PP2E.PyTools.visitor import FileVisitor

instead of the correct

from PP3E.PyTools.visitor import FileVisitor

There are 18 other files in the pack with potentially the same problem:

$ python PyTools/visitor_collect_quiet1.py 'from PP2E'
Found these files:
./Dstruct/TreeView/alts/treeview_left.py
./Dstruct/TreeView/alts/treeview_subclass.py
./Integrate/Extend/Stacks/exttime.py
./PyTools/visitor_poundbang.py
./PyTools/wcall_find.py
./PyTools/wcall_find_patt.py
./System/App/apptools.py
./System/App/Clients/mtool3.py
./System/App/Clients/mtoolapp.py
./System/App/Clients/myapp.py
./System/App/Clients/myapp2.py
./System/App/Clients/myapp4.py
./System/App/Clients/tools.py
./System/App/Clients/tools2.py
./System/App/Clients/unpackapp2.py
./System/App/Kinds/interact.py
./System/App/Kinds/internal.py
./System/App/Tests/apptest.py


[523] The example;
Line 46 of the simpleedit.py example causes a run-time exception to be thrown using Python 2.5:

Exception in Tkinter callback
Traceback (most recent call last):
File "/home/jdavies/devl/projects/devtools/Python-2.5.1/Lib/lib-tk/Tkinter.py", line 1403, in __call__
return self.func(*args)
File "simpleedit.py", line 46, in onFind
pastit = where + ('+%dc' % len(target)) # index past target
TypeError: unsupported operand type(s) for +: '_tkinter.Tcl_Obj' and 'str'


{646}  Example 12-3;
PyEdit has a legacy import of the form "from PP2E.Gui.Tools..." which must 
be "from PP3E.Gui.Tools..." in order to run. This was fixed in the examples 
distribution, but not in the book. It reflects the fact that the examples 
were scattered between two directory trees during development of this 
edition; this reference slipped through the cracks when the trees were merged.



(825)  3rd paragraph (in box; code example);
The code example in the box is missing a couple of newlines:

1. The first line is

 import timegmt = time.gmtime(time.time())

but should be

 import time
 gmt = time.gmtime(time.time())

2. The last line reads

 hdr = 'Date: ' + strprint hdr

but should be

 hdr = 'Date: ' + str
 print hdr


(1010)  Example 16-15;
There seems to be an extra and superfluous "<form>" tag in this HTML file; 
you may have to delete one of the two to make this example work. This was 
fixed in the examples distribution package, but not in the book.


(1539)N section of index;
no index entry for "not" Python keyword