diff --git a/advanced-iterators.html b/advanced-iterators.html index dca9dab..711a49c 100644 --- a/advanced-iterators.html +++ b/advanced-iterators.html @@ -514,7 +514,7 @@ NameError: name 'math' is not defined 
 >>> eval("__import__('subprocess').getoutput('rm -rf /')", {}, {})  ①
    -
  1. Please don’t do this.
    2. +
  2. Please don’t do this.

Oops. I’m glad I didn’t make that alphametics web service. Is there any way to use eval() safely? diff --git a/case-study-porting-chardet-to-python-3.html b/case-study-porting-chardet-to-python-3.html index d4fdb13..242690b 100644 --- a/case-study-porting-chardet-to-python-3.html +++ b/case-study-porting-chardet-to-python-3.html @@ -618,7 +618,7 @@ import sys

Onward!

Name 'file' is not defined

-

And here we go again, running test.py to try to execute our test cases…

+

And here we go again, running test.py to try to execute our test cases… 

C:\home\chardet> python test.py tests\*\*
 tests\ascii\howto.diveintomark.org.xml
 Traceback (most recent call last):
@@ -700,7 +700,7 @@ TypeError: Can't convert 'bytes' object to str implicitly

There’s an unfortunate clash of coding style and Python interpreter here. The TypeError could be anywhere on that line, but the traceback doesn’t tell you exactly where it is. It could be in the first conditional or the second, and the traceback would look the same. To narrow it down, you should split the line in half, like this: 

elif (self._mInputState == ePureAscii) and \
     self._escDetector.search(self._mLastChar + aBuf):
-

And re-run the test:

+

And re-run the test: 

C:\home\chardet> python test.py tests\*\*
 tests\ascii\howto.diveintomark.org.xml
 Traceback (most recent call last):
diff --git a/index.html b/index.html
index b5ac513..a0de802 100644
--- a/index.html
+++ b/index.html
@@ -20,7 +20,7 @@ h1:before{content:""}
 
 
Dive Into Python 3 will cover Python 3 and its differences from Python 2. Compared to the original Dive Into Python, it will be about 50% revised and 50% new material. I will publish drafts online as I go. The final version will be published on paper by Apress. The book will remain online under the CC-BY-SA-3.0 license.
 
-
You can see the full table of contents (not finalized), or read what I’ve written so far:

+
You can see the full table of contents (not finalized), or read what I’ve written so far:
 
 
    
 
  1. What’s New in “Dive Into Python 3”
diff --git a/iterators.html b/iterators.html
index 8e8ac5a..dd52516 100644
--- a/iterators.html
+++ b/iterators.html
@@ -173,7 +173,7 @@ class Fib:
 
  2. To spit out the next value, an iterator’s __next__() method simply returns the value. Do not use yield here; that’s a bit of syntactic sugar that only applies when you’re using generators. Here you’re creating your own iterator from scratch; use return instead.
 

 
-
Thoroughly confused yet? Excellent. Let’s see how to call this iterator:

+
Thoroughly confused yet? Excellent. Let’s see how to call this iterator:
 
 
 >>> from fibonacci2 import Fib
diff --git a/unit-testing.html b/unit-testing.html
index 39497de..47bcd0a 100644
--- a/unit-testing.html
+++ b/unit-testing.html
@@ -27,7 +27,7 @@ body{counter-reset:h1 8}
 
  • There is no way to represent negative numbers in Roman numerals.
 
  • There is no way to represent fractions or non-integer numbers in Roman numerals.
 
-
    Let’s start mapping out what a roman.py module should do.  It will have two main functions, to_roman() and from_roman(). The to_roman() function should take an integer from 1 to 3999 and return the Roman numeral representation as a string…
    
+
    Let’s start mapping out what a roman.py module should do.  It will have two main functions, to_roman() and from_roman(). The to_roman() function should take an integer from 1 to 3999 and return the Roman numeral representation as a string…
 
    Stop right there. Now let’s do something a little unexpected: write a test case that checks whether the to_roman() function does what you want it to. You read that right: you’re going to write code that tests code that you haven’t written yet.
 
    This is called unit testing.  The set of two conversion functions — to_roman(), and later from_roman() — can be written and tested as a unit, separate from any larger program that imports them. Python has a framework for unit testing, the appropriately-named unittest module.
 
    Unit testing is an important part of an overall testing-centric development strategy. If you write unit tests, it is important to write them early (preferably before writing the code that they test), and to keep them updated as code and requirements change. Unit testing is not a replacement for higher-level functional or system testing, but it is important in all phases of development: