Programming Python

Errata for Programming Python

Submit your own errata for this product.


The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted Date Corrected
PDF, Other Digital Version
Page xxviii
at top of page in continuation of previous paragraph

"Only a fraction of Python users must care about linking in C libraries today, and those who do already have the skills required to read the larger and more ***compete*** example of integration present in the source code of Python itself." Type at ***, suppose to be complete? It's in pdf and epub that I just got.

Note from the Author or Editor:
Yes - a typo. Please fix in reprints.

Anonymous  Dec 16, 2010  May 13, 2011
, Printed, PDF, Safari Books Online, Other Digital Version
Page xxviii
line 3 from page top

[Feb-1-11] Page xxviii, line 3 from page top: two typos in same sentence This text's "larger and more compete example" should be "larger and more complete examples".

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Feb 02, 2011  May 13, 2011
Printed, PDF, ePub, Mobi, Safari Books Online, Other Digital Version
Page N/A
N/A

There is a new patch for running PyMailGUI under Python 3.3, which fixes a display issue for non-ASCII email address names introduced by an incompatible change in Python's email package. For details and the simple patch, please see: http://rmi.net/~lutz/pp4e-updates.html#py33emailfix

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Sep 15, 2013 
Printed, PDF, ePub, Mobi, Safari Books Online
Page N/A
N/A

[Oct 2013] There's a new release of the book's examples package, updated for Python 3.3. Examples in this 1.4 release work with all 3.X Pythons 3.3 and earlier (and possibly later). It's available at the book's official examples site: http://examples.oreilly.com/9780596158118/ For details on the minor changes incorporated, as well as 3.3 usage pointers, see the package's new README file at either the preceding site or here: http://www.rmi.net/~lutz/README-PP4E-PY33.html

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Oct 16, 2013 
Printed, PDF, Safari Books Online, Other Digital Version
Page 12
5th Python prompt

Python prompt has two angled-brackeds, instead of three: >> bob2['job'][-1] should read: >>> bob2['job'][-1]

Note from the Author or Editor:
Yes -- add an extra ">" to the ">>" prompt here (it should be ">>>").

Daniel Díaz  Mar 24, 2011  Nov 11, 2011
Printed
Page 21
Example 1-7 heading

The Example 1-7 heading lists the filename as update-db-pickle.py when it should be update_db_pickle.py.

Note from the Author or Editor:
Yes -- fix as described (use underscores instead of dashes to match the file's name in later interaction).

Brad Trotter  May 24, 2011  Nov 11, 2011
Printed
Page 38/39
example 1-22

example 1-22 peopleinteract_update.py: Neither my typed code nor the cut and paste code from the online example code at O'reilly produce the result printed in the paperback edition. This code contains both formatting errors and logic errors.

Note from the Author or Editor:
This reflects a bug in Python 3.2.0, not in the book's examples. Please see: http://www.rmi.net/~lutz/lp4e-updates-notes-recent.html#py320inputbug for details. In short, Python's input() built-in is broken in 3.2.0 (3.2) when used in Windows console mode only. This built-in has been fixed in later Python releases. The quickest fix is to upgrade to 3.2.1 or later, or try a different environment; examples in the book which use input() work fine in all other Python versions and in most other contexts such as IDLE.

Charles Wehrenberg  Dec 14, 2011 
Printed
Page 63, 67
markup code

Because of the evolving html standard, as of the publication for the fourth edition of this book, the html table elements (<tr>, <th>, <td>) should specify closing code (</tr>, </th>, </td>.

Note from the Author or Editor:
[No change required] The book states clearly that it omits some HTML tags on purpose for simplicity and space. I agree with this poster's point in principle, but it doesn't merit changes in the book given its explicit and broad statements on this point.

charlie@solozone.com  Dec 01, 2011 
Printed
Page 152
2nd example

Reads bytes = file.read() values = struct.unpack('>>i4shf', data) NameError: name 'data' is not defined Should read as data = file.read() values = struct.unpack('>>i4shf', data)

Note from the Author or Editor:
Yes -- change as described: page 152, 2nd code listing, line 4 should read as follows (change "bytes" at the end to "data"): values = struct.unpack('>>i4shf', data) The code actually works as is if you keep typing all the code on this page in sequence (as I must have done), because "data" is what we called the byte string when it was written to the file; that is, "data" from the first interaction is the same as the "bytes" read off the file in the second interaction. This wasn't the intent, though.

Bob Sanford  May 24, 2011  Nov 11, 2011
Printed
Page 152
first example; second line

Running Python 3.2.2 on Win 7 machine EXISTING data = struct.pack('>i4shf', 2, 'spam', 3, 1.234) NEEDS BINARY b & SHOULD READ data = struct.pack('>i4shf', 2, b'spam', 3, 1.234) this correction is suggested by the values = return in the second example.

Note from the Author or Editor:
This reflects a recent change in Python 3.2, not a problem with the book examples. In short, 3.2 has removed existing struct.pack functionality for str strings and the "s" type code, and now allows only bytes strings in this context. In 3.2 and later, you must manually encode Unicode str to bytes prior to this tool, using str.encode() or bytes(). This change also impacts some examples in Learning Python, and one example in Python Pocket Reference. For more details, including the fix, please see this note on my book update pages (or its cross-post on Programming Python's updates page): http://www.rmi.net/~lutz/lp4e-updates-notes-recent.html#py32structchange I can't post here about every change in Python that will impact the books over time, but this change seemed to merit a few words.

Charles Wehrenberg  Jan 07, 2012 
Printed, PDF, ePub
Page 322
code block 2

"C:\...\PP4E\Tools> python find.py *.py .. | more" It seems I have to quote "*.py" for this command to work in Linux. Didn't try Windows though.

Note from the Author or Editor:
Changing this to a clarification, not an errata. To address, change the very end of paragraph 2 on Page 322 from: "...standard input stream:" to: "...standard input stream (remember to quote the "*.py" on Unix and Linux shells only, to avoid premature pattern expansion):" [DISCUSSION ONLY FOLLOWS] The report is correct about needing to quote some command-line arguments on Linux (only), and this does merit a note here. This finder directory tree search script matches the passed-in "*.py" pattern itself, so we don't want a Linux shell to do expansion before it's passed in. However, shell differences are mentioned elsewhere; this book runs all its examples on Windows, where this isn't an issue; and the book cannot note shell differences at each command where syntax diverges without becoming a shell programming guide too. On this specific point, the following text appears on Page 106 (before the command line in question) in an early section devoted to command lines in general: """ (portability note: you may need to add quotes around the *.py in this and other command-line examples to prevent it from being expanded in some Unix shells): """ Moreover, Unix shell globbing behavior is also described on the earlier Page 166, and the closer Page 320-321. Both linear readers of the book and Linux users in general should probably be aware of the issue well enough to argue against redundant warnings throughout an already large text (and quoting arguments in general for Linux readers would likely confuse others with less command-line experience to draw from). Nevertheless it's worth adding the text in the book and retaining this note as a reminder for Linux readers here -- thanks for the report.

Yang Lifu  Sep 09, 2013  Jan 17, 2014
Printed, PDF, ePub, Mobi, Safari Books Online
Page 631
Source code def configBorders

The method of setting a window icon as used in the generic _window class, does not work on linux. This seems to be part because the .ico file is only for windows and part because tk has a hard time decoding any image file. Following code seems to work: root = Tk() img = PhotoImage(file='your-icon') root.tk.call('wm', 'iconphoto', root._w, img)

Note from the Author or Editor:
[Changing this report's type from minor technical mistake to clarification, and no change is required: informational only.] It's true that Windows ".ico" files won't generally work on Linux, but: 1) This is pretty clearly explained in a big paragraph on page 424, where tk's iconbitmap call is first covered in depth, and mentioned parenthetically on page 44 at a preview example (plus, the book makes its use of Windows for running examples explicit throughout). 2) The _window class on Page 631 referred to in this post should not cause its clients to fail on Linux, as it wraps the icon call in a exception handler and simply ignores the error on other platforms (to be verified, but it should only skip the custom window icon step and continue). So, this isn't an errata per se; the example works as shown, and requires tweaking outside Windows for custom icons as described in the book. That's one of the unavoidable platform dependencies of GUIs, and it wasn't possible to cover every variant. That said, I'm retaining this note here as a constructive and useful pointer for other Linux readers who may want to use a custom window icon too; thanks for the suggestion. On Linux, you'll probably also want to customize the _window class's iconpatt string, used to search for an icon file automatically if none is passed in (see the code: it's "'*.ico" as is).

Rob van der Most  Oct 06, 2013 
, Printed, PDF, Safari Books Online, Other Digital Version
Page 678
line 3 of last paragraph on page

[Feb-1-11] Page 678 in Chapter 11, line 3 of last paragraph on page, figure description off The text misstates Figure 11-4's content here: it does not show a Clone window (the original version of this screenshot did, but was retaken very late in the project to show Grep dialogs with different Unicode encodings). To fix, change this line's "a window and its clone" to read "a main window".

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Feb 02, 2011  May 13, 2011
, Printed, PDF, Safari Books Online, Other Digital Version
Page 702 and 704
see detailed description

[For a detailed description of this item, as well as the correct whitespace in the patch, please see: http://www.rmi.net/~lutz/pp4e-updates.html#closenote http://www.rmi.net/~lutz/pp4e-updates.html#closepatch ] [Feb-1-11] Page 702 and 704, PyEdit: add text.focus() calls after askstring() Unicode popups For convenience, and per the detailed description above, we should add a call to reset focus back to the text widget after the Unicode encoding prompt popups which may be issued on Open and Save/SaveAs requests (depending on texconfig settings). As is, the code works, but requires the user to click in the text area if they wish to resume editing it immediately after the Unicode popup is dismissed; this standard popup itself should probably restore focus, but does not. To fix, add focus calls in two places. First, on page 702, at code line 21 at roughly mid page, change: if askuser: try: text = open(file, 'r', encoding=askuser).read() to the following, adding the new first line (the rest of this code is unchanged): self.text.focus() # else must click if askuser: try: text = open(file, 'r', encoding=askuser).read() Second, on page 704, at code line 8 near top of page, similarly change: if askuser: try: text.encode(askuser) to the following, again just adding the new first line: self.text.focus() # else must click if askuser: try: text.encode(askuser) Reprints: please let me know if there is not enough space for the inserts; I'd rather avoid altering page breaks in the process. This patch will also be applied to future versions of the book's examples package; in the package, the code in question is in file PP4E\Gui\TextEditor\textEditor.py, at lines 298 and 393.

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Feb 02, 2011  May 13, 2011
, Printed, PDF, Safari Books Online
Page 963, 970
Page 963 line 9, and page 970 line 4

Page 963 line 9, and page 970 line 4: add timeout arguments to email server connect calls For robustness, add "timeout=15" arguments to the POP and SMTP connect calls, so that email clients don't hang when email servers fail to respond. In the book, change code line 9 on page 963 from the first of the following to the second: server = smtplib.SMTP(self.smtpServerName) # this may fail too server = smtplib.SMTP(self.smtpServerName, timeout=15) # this may fail too Similarly, change code line 4 on page 970 from the first of the following to the second: server = poplib.POP3(self.popServer) server = poplib.POP3(self.popServer, timeout=15) In the book examples package, these changes would be applied to line 153 of mailSender.py, and line 34 of file mailFetcher.py, both of which reside in directory PP4E\Internet\Email\mailtools. They'll be patched in a future examples package version. Not a bug, but a desired enhancement. For more background on this, see my updates page: http://www.rmi.net/~lutz/pp4e-updates.html#timeoutnote

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Feb 22, 2011  May 13, 2011
, Printed, PDF, Safari Books Online, Other Digital Version
Page 978, 964
mid page (see description)

[Oct-20-11] Pages 978 and 964, encode and decode i18n attachment filenames for display, save, send Per the detailed description at http://www.rmi.net/~lutz/pp4e-updates.html#filenamespatch, the following two changes will support both receipt and send of encoded i18n attachment filenames, assuming that such non-ASCII filenames are valid on the underlying platform (Windows is very liberal in this regard). First, on Page 978, change the very last line of the partName method def statement from the first of these to the second (this is mid page at code line 26, in file PP4E\Internet\Email\mailtools\mailParser.py -- be careful of indentation of the code and its "#" comment which is given more exactly in the detailed description named above): return (filename, contype) return (self.decodeHeader(filename), contype) # oct 2011: decode i18n fnames Second, on Page 964, change the 5th and 4th last lines of the addAttachments method def statement from the first of these to the second (this is mid page line -22, in file P4E\Internet\Email\mailtools\mailSender.py): # set filename and attach to container basename = os.path.basename(filename) # set filename (ascii or utf8/mime encoded) and attach to container basename = self.encodeHeader(os.path.basename(filename)) # oct 2011 These were also patched in version 1.3 of the book examples package (PP4E-Examples-1.3.zip); see http://www.rmi.net/~lutz/pp4e-updates.html#pymailguiall for details.

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Oct 20, 2011  Nov 11, 2011
, Printed, PDF, Safari Books Online, Other Digital Version
Page 1072
code line 10 from top of page

[For a detailed description of this item, as well as the correct whitespace in the patch, please see: http://www.rmi.net/~lutz/pp4e-updates.html#closenote http://www.rmi.net/~lutz/pp4e-updates.html#closepatch ] [Feb-1-11] Page 1072, code line 10 from top of page, PyMailGUI: add a close() for HTML mail files For portability, and per the detailed description above, we should add an explicit close() call to flush the temporary file of an HTML-only email before starting a web browser to view it, so that this code works in all contexts. As is, it works on the test platform used for the book, and likely works on most others, because the method in question exits and thus reclaims, closes, and flushes the file before the spawned web browser gets around to reading it. However, this is timing and platform dependent, and may fail on some machines that start browsers more quickly; its been seen to fail on a fast Vista machine. To fix in the book, change the middle line of the following three current code lines: tmp = open(tempname, 'wb') # already encoded tmp.write(asbytes) webbrowser.open_new('file://' + tempname) to read as follows, adding the text that starts with the semicolon (I'm combining statements to avoid altering page breaks): tmp = open(tempname, 'wb') # already encoded tmp.write(asbytes); tmp.close() # flush output now webbrowser.open_new('file://' + tempname) In the book's examples package, this code is located at line 209 in file PP4E\Internet\Email\PyMailGUI\ListWindows.py; it will be patched there too in a future examples package release (version 1.2, date TBD).

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Feb 02, 2011  May 13, 2011
, Printed, PDF, Safari Books Online, Other Digital Version
Page 1226
sidebar on page

[Feb-1-11] Page 1226, two filename typos in same sidebar This will probably be obvious to most readers who inspect the external example files referenced here, but in this sidebar: "test-cgiu-uploads-bug*" should read "test-cgi-uploads-bug*", and the bullet item text "test-cgi-uploads-bug.html/py saves the input stream" should read "test-cgi-uploads-bug2.html/py saves the input stream".

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Feb 02, 2011  May 13, 2011
, Printed, PDF, Safari Books Online, Other Digital Version
Page 1555
heading line at top of page

[Feb-1-11] Page 1555, top of page, quotes are misplaced in heading line A typo inherited from the prior edition: the quotes and question mark in the heading line at the very top of this page are slightly off. Change the heading line: So What’s “Python: The Sequel”? to read as: “So What’s Python?”: The Sequel. This header refers back to the sidebar in the Preface titled "So What's Python?". Arguably trivial, as this sidebar was 1500 pages (and perhaps a few months) ago by this point in the book, but it would be better to get this right. This header was broken by a copyedit change on the prior edition, and fell through the cracks on this one.

Mark Lutz
O'Reilly AuthorO'Reilly Blogger 
Feb 02, 2011  May 13, 2011