diff --git a/files.html b/files.html index 9c945bb..9decc06 100644 --- a/files.html +++ b/files.html @@ -33,8 +33,21 @@ open(..., 'r', encoding='...')

Character Encoding Rears Its Ugly Head

+

Bytes are bytes; characters are an abstraction. A string is a sequence of Unicode characters. But a file on disk is not a sequence of Unicode characters; a file on disk is a sequence of bytes. So if you read a “text file” from disk, how does Python convert that sequence of bytes into a sequence of characters? It decodes the bytes according to a specific character encoding algorithm, and returns a sequence of Unicode characters, otherwise known as a string. + +

+# on Windows...
+>>> file = open('examples/chinese.txt')
+>>> a_string = file.read()
+Traceback (most recent call last):
+  File "", line 1, in 
+  File "C:\Python31\lib\encodings\cp1252.py", line 23, in decode
+    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
+UnicodeDecodeError: 'charmap' codec can't decode byte 0x8f in position 28: character maps to 
+>>>
+
+ diff --git a/installing-python.html b/installing-python.html index cb6f6ea..c49c9da 100755 --- a/installing-python.html +++ b/installing-python.html @@ -51,7 +51,7 @@ Type "help", "copyright", "credits" or "license" for more information. mark@manganese:~$ python3 bash: python3: command not found -

So back to the question that started this section, “Which Python is right for you?” The answer is whichever one runs on the computer you already have. +

So back to the question that started this section, “Which Python is right for you?” Whichever one runs on the computer you already have.

[Read on for Windows instructions, or skip to Installing on Mac OS X, Installing on Ubuntu Linux, or Installing on Other Platforms.] diff --git a/special-method-names.html b/special-method-names.html index dfb5e33..1fafe34 100644 --- a/special-method-names.html +++ b/special-method-names.html @@ -437,7 +437,7 @@ class FieldStorage:

This is not a case of taking a Fraction and dividing it by an integer (as in the previous example). That case was straightforward: x / 3 calls x.__truediv__(3), and the __truediv__() method of the Fraction class handles all the math. But integers don’t “know” how to do arithmetic operations with fractions. So why does this example work? -

The answer lies in a second set of arithmetic special methods with reflected operands. Given an arithmetic operation that takes two operands (e.g. x / y), there are two ways to go about it: +

There is a second set of arithmetic special methods with reflected operands. Given an arithmetic operation that takes two operands (e.g. x / y), there are two ways to go about it:

  1. Tell x to divide itself by y, or diff --git a/unit-testing.html b/unit-testing.html index 1cc4a02..c8338a6 100755 --- a/unit-testing.html +++ b/unit-testing.html @@ -276,7 +276,7 @@ Ran 2 tests in 0.000s FAILED (errors=1)
    1. You should have expected this to fail (since you haven’t written any code to pass it yet), but... it didn’t actually “fail,” it had an “error” instead. This is a subtle but important distinction. A unit test actually has three return values: pass, fail, and error. Pass, of course, means that the test passed — the code did what you expected. “Fail” is what the previous test case did (until you wrote code to make it pass) — it executed the code but the result was not what you expected. “Error” means that the code didn’t even execute properly. -
    2. Why didn’t the code execute properly? The traceback gives the answer: the module you’re testing doesn’t have an exception called OutOfRangeError. Remember, you passed this exception to the assertRaises() method, because it’s the exception you want the function to raise given an out-of-range input. But the exception doesn’t exist, so the call to the assertRaises() method failed. It never got a chance to test the to_roman() function; it didn’t get that far. +
    3. Why didn’t the code execute properly? The traceback tells all. The module you’re testing doesn’t have an exception called OutOfRangeError. Remember, you passed this exception to the assertRaises() method, because it’s the exception you want the function to raise given an out-of-range input. But the exception doesn’t exist, so the call to the assertRaises() method failed. It never got a chance to test the to_roman() function; it didn’t get that far.

    To solve this problem, you need to define the OutOfRangeError exception in roman2.py. 

    class OutOfRangeError(ValueError):  ①