Merge branch 'main' of https://github.com/tomasff/cross-society-python-course

Author: Levelent

week6/w6.ipynb

@@ -6,7 +6,7 @@
    "source": [
     "# **xSoc Python Course** - Week 6\n",
     "\n",
-    "### *Efficiency, Compactness, Readability*\n",
+    "### *Efficiency, Compactness & Readability*\n",
     "\n",
     "🖋️ *Written by Alia & Keegan from the [Computing Society](https://go.uwcs.uk/links)*"
    ]
@@ -43,9 +43,9 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Seems fine? But what if the user decides they *don't* want to enter a number, what if, e.g., they enter \"Hello\"? Python doesn't know how to convert a string to an integer, so it will throw a **ValueError** and exit the program.\n",
+    "Seems fine? But what if the user decides they *don't* want to enter a number, what if, e.g., they enter \"Hello\"? Python doesn't know how to convert a string to an integer, so it will throw a `ValueError` and exit the program.\n",
     "\n",
-    "In reality, entering the wrong type of data isn't the end of the world. To stop Python from exiting immeadiately, we can surround any potentially problem-causing code in a `try-expect` block like this:"
+    "In reality, entering the wrong type of data isn't the end of the world. To stop Python from exiting immediately, we can surround any potentially problem-causing code in a `try-except` block like this:"
    ]
   },
   {
@@ -66,7 +66,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "The `try` statement tells the Python interpreter that something could go wrong in the following statements, but we know and have ways to deal with it. \n",
+    "The `try` statement tells the Python interpreter that something could go wrong in the following statements, but we know and have ways to deal with it. Any statements after the `try-except` block will execute normally, even if a `ValueError` is raised.\n",
     "\n",
     "Note: we need `num *= 2` and `print(num)` in the `try` block because if the user inputs something wrong, `num` won't be defined. If the statements were *after* the try statement, this could cause an error as `num` wouldn't be defined.\n",
     "\n",
@@ -139,7 +139,7 @@
    "source": [
     "Try running the above block and input a string. Now input 0. We've caused two different errors, but the same statement is being executed. Why?\n",
     "\n",
-    "Since all exceptions are a subclass of **Exception**, Python considers them to be of type *Exception*. Why does this matter? Python executes the *first relevant* catch statement - in this case it will *always* be an Exception, so the first statement will execute *regardless* of what type of exception we're throwing. You need to make sure that you put any catch statements for subclasses *above* those of their parent classes, otherwise the subclasses will never execute:"
+    "Since all exceptions are a subclass of **Exception**, Python considers them to be of type **Exception**. Why does this matter? Python executes the *first relevant* except statement - in this case it will *always* be an Exception, so the first statement will execute *regardless* of what type of exception we're throwing. You need to make sure that you put any except statements for subclasses *above* those of their parent classes, otherwise the subclasses will never execute:"
    ]
   },
   {
@@ -194,7 +194,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "We can also write our own custom exceptions. We define them the same way we define a class, making sure to say it inherits from **Exception**. Then, we can call it anywhere in our code by using `raise`:"
+    "We can also write our own custom exceptions. We define them the same way we define a class, making sure it inherits from **Exception**. Then, we can call it anywhere in our code by using `raise`:"
    ]
   },
   {
@@ -497,7 +497,7 @@
    "metadata": {},
    "source": [
     "![pascal.png](attachment:pascal.png)"
-   ]
+    ]
   },
   {
    "cell_type": "markdown",
@@ -671,7 +671,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "The fancier name for this is a **binary search**, because at each step, we're dividing the search space we have left into 2. So, how much faster is this method than a regular, linear search? Well, for small lists you won't see much improvement, but for larger lists, say, with $n$ items, we only need to check $\\log(n)$ of them in the worst case! The difference couldn't be clearer:"
+    "The fancier name for this is a **Binary Search**, because at each step, we're dividing the search space we have left into 2. So, how much faster is this method than a regular, linear search? Well, for small lists you won't see much improvement, but for larger lists, say, with $n$ items, we only need to check $\\log(n)$ of them in the worst case! The difference couldn't be clearer:"
    ]
   },
   {
@@ -684,7 +684,7 @@
    "metadata": {},
    "source": [
     "![Picture3.png](attachment:Picture3.png)"
-   ]
+    ]
   },
   {
    "cell_type": "markdown",
@@ -1370,8 +1370,7 @@
   },
   "vscode": {
    "interpreter": {
-    "hash": "7c57092efe4ff60dfd9ba12cd3127c3cb8001227526172b4b54478afc6e523e7"
-   }
+    "hash": "7c57092efe4ff60dfd9ba12cd3127c3cb8001227526172b4b54478afc6e523e7"}
   }
  },
  "nbformat": 4,