The "bitwise complement" operator is incorrectly represented by an odd symbol (http://safari.oreilly.com/images/ent/U02DC.GIF, a circle with a tilde on top) rather than a simple tilde (~).

All double underscores are incorrectly separated by a space character.
e.g., The method name "__init__" is displayed as "_ _init_ _".

The "Octal digits value" entry in the table is incorrectly listed as "\ooo" when it should be "\000"

This is an excellent book. Very easy to follow and learn from. Thanks!
I discovered an errata on page 101 that does not appear to be documented yet:

>>> "%e" % num
'3.333333e-001'

...should be...

>>> "%e" % num
'3.333333e-01'

There is an extra zero in the exponent in the book.

The example states:

>>> 'SPAM'.join(['eggs', 'sausage', 'ham', 'toast'])
'eggsSPAMsausaugeSPAMhamSPAMtoast'

I believe this should be:

'eggsSPAMsausaugeSPAMhamSPAMtoastSPAM'

(3rd edition)

The table shows dict.fromvalues(['a', 'b']) as an alternative dictionary construction technique, but
there is no such method as "fromvalues" for the dictionary object.

Page 170 shows dict.fromkeys(['a', 'b'], 0), which is valid and probably what belongs in the table.

1) In the text:
or a series of assignments like D = [], D['a'] = 0, D['b'] = 0

"D = []" should be "D = {}"

2) The last sentence of this paragraph, "because all the keys are the same", should be "because all the
values are the same".

In the Operation column; the second last row says outout.flush(). It won't work it needs to be
output.flush()

Python caching of string objects is not optimized solely on the basis of string length, but also factor in string composition, and thus the code examples can lead to the wrong conclusion.

As an example, if you execute the following interactively:

>>> s1 = 'a b'
>>> s2 = 'a b'
>>> s1 == s2, s1 is s2
(True, False)
>>> s1 = 'asdfasdfasdfasdfasdfasdfasdfasdf'
>>> s2 = 'asdfasdfasdfasdfasdfasdfasdfasdf'
>>> s1 == s2, s1 is s2
(True, True)

In this case 3-character strings are stored in separate objects. However 32-character strings are cached with references to the same object. The difference lies in the embedded whitespace, which separates 'words' in a classical string sense.

Now consider the following:

>>> s1 = 'a,b'
>>> s2 = 'a,b'
>>> s1 == s2, s1 is s2
(True, False)
>>> s1 = 'a1b'
>>> s2 = 'a1b'
>>> s1 == s2, s1 is s2
(True, True)

This behavior indicates that one-word alpha-numeric strings are processed and cached, but that whitespace/special-character containing strings are not cached to the same object.

In practical terms this might affect the fledgling coder's approach, as he/she might assume that the "short" repetitious strings common to multiple objects, such as database records, could be instantiated hundreds at a time without growing the number of objects, only references. In fact that is not true if these "short strings" are not one-word alphanumeric.

A bit of nuance, but I think it is an interesting note for those interested in the implementation of Python as a language, and could be important for those who conduct large-scale textual data-mining using Python as a bed.

The type "Set" is listed as a number type in figure 9-3, while
the correct is that it is a collection type. At least that
is what it says on page 108 (in the same book).

The Python 2.5 and 2.6 interpreters don't like the print statement outside the while loop. I get the following error at runtime:

while True:
reply=raw_input('Enter text:')
if reply=='stop': break
print int(reply)**2
print 'Bye'
^

sytax error:invalid syntax


The error is fixed by putting the print statement inside the loop:

if reply=='stop': print 'Bye'; break


This is also the case for the examples on pages 213 and 214.

The following example is missing the Bye statement after the stop input is made:

Enter text:5
25
Enter text:xyz
Bad!Bad!Bad!Bad!Bad!Bad!Bad!Bad!
Enter text: 10
100
Enter text:stop

First line should read
def knights(name)

Fourth line should read
return action(name)

The book states that:
[T]he expression ((a and b) or c) is roughly equivalent to:

if a:
b
else:
c

However, plugging in values a=1, b=0, and c=1 will give different answers for the two logical statements:

((1 and 0) or 1) evaluates to 1, while

if 1:
0
else:
1

evaluates to 0.

In the Why You Will Care: File Scanners box, second to last code example,
xreadlines() is presented as an option. According to the Python Library
Reference, xreadlines() is "...Deprecated since release 2.3. Use "for line
in file" instead."

http://docs.python.org/lib/bltin-file-objects.html

The user typed command
">>> print open.__doc__"
does not match with the printed output
"file(name[, mode[, bhuffering]]) -> file object".
The correct user typed command has to be instead
">>> print file.__doc__"

The last line in the code sample has a typo. Instead of

print 'Got', sys.exc_info(){0], ....

it should say

print 'Got', sys.exc_info()[0], ....