minor tweaks

Author: fbaptiste

Part 2/Section 03 - Project 1/02 - Project Solution - Goal 1.ipynb

@@ -1093,7 +1093,7 @@
    "source": [
     "By the way, did you notice that we spent at the same, if not more, amount of time **testing** our code as we did **writing** it?\n",
     "\n",
-    "In practice, that is often how that goes - you should always test your code - you obviously cannot test every case, but you should always try to test everything at least once, and then also cover edge cases if there are any.\n",
+    "In practice, that is often how that goes - you should always test your code - you obviously cannot test every data combination, but you should always try to test all your methods and code branches at least once (coverage), and then also cover edge cases if there are any to make sure those are handled as expected.\n",
     "\n",
     "You should also try to ensure, within reason, that all the code you wrote is tested (i.e. executed, or *exercised*) during your tests - this is called **test coverage**, or sometimes **code coverage**."
    ]

Part 2/Section 05 - Project 2/02 - Project Solution - Goal 1.ipynb

@@ -8,17 +8,19 @@
    ]
   },
   {
-   "cell_type": "raw",
+   "cell_type": "markdown",
    "metadata": {},
    "source": [
+    "Our starting point is where we left off at the end of Project 1.\n",
+    "\n",
     "Our first goal is to rewrite all properties as lazy properties."
    ]
   },
   {
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Here is where we left off with the Polygon class in the previous project:"
+    "Here is the code we ended up with in Project 1:"
    ]
   },
   {
@@ -103,7 +105,9 @@
   {
    "cell_type": "code",
    "execution_count": 13,
-   "metadata": {},
+   "metadata": {
+    "collapsed": true
+   },
    "outputs": [],
    "source": [
     "class Polygon:\n",
@@ -182,7 +186,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "And let's run the same unit test we wrote for the earlier project:"
+    "And let's run the same unit test we wrote for Project 1:"
    ]
   },
   {
@@ -278,7 +282,9 @@
   {
    "cell_type": "code",
    "execution_count": 15,
-   "metadata": {},
+   "metadata": {
+    "collapsed": true
+   },
    "outputs": [],
    "source": [
     "test_polygon()"

Part 2/Section 06 - Generators/02 - Example - Fibonacci Sequence.ipynb

@@ -44,7 +44,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Although we can certainly use a recursive approach to calculate the *n-th* number in the sequence, it is not a very effective method - we can of course help it by using memoization, but we'll still run in Python's maximum recursion depth (which we can change also) - but overall it's not very efficient:"
+    "Although we can certainly use a recursive approach to calculate the *n-th* number in the sequence, it is not a very effective method - we can of course help it by using memoization, but we'll still run into Python's maximum recursion depth. In Python there is a maximum number of times a recursive function can call itself (creating a stack frame at every nested call) before Python gives us an exception that we have exceeded the maximum permitted depth (the number of recursive calls). We can actually change that number if we want to, but if we're running into that limitation, it might be better creating a non-recursive algorithm - recursion can be elegant, but not particularly efficient."
    ]
   },
   {