diff --git a/README.md b/README.md
index be27847..7fffe0c 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-
+
What the f*ck Python! 🐍
An interesting collection of surprising snippets and lesser-known Python features.
@@ -203,11 +203,10 @@ Makes sense, right?
* All length 0 and length 1 strings are interned.
* Strings are interned at compile time (`'wtf'` will be interned but `''.join(['w', 't', 'f']` will not be interned)
* Strings that are not composed of ASCII letters, digits or underscores, are not interned. This explains why `'wtf!'` was not interned due to `!`. Cpython implementation of this rule can be found [here](https://github.com/python/cpython/blob/3.6/Objects/codeobject.c#L19)
-
+
+ When `a` and `b` are set to `"wtf!"` in the same line, the Python interpreter creates a new object, then references the second variable at the same time. If you do it on separate lines, it doesn't "know" that there's already `wtf!` as an object (because `"wtf!"` is not implicitly interned as per the facts mentioned above). It's a compiler optimization and specifically applies to the interactive environment.
+ Constant folding is a technique for [peephole optimization](https://en.wikipedia.org/wiki/Peephole_optimization) in Python. This means the expression `'a'*20` is replaced by `'aaaaaaaaaaaaaaaaaaaa'` during compilation to reduce few clock cycles during runtime. Constant folding only occurs for strings having length less than or equal to 20. (Why? Imagine the size of `.pyc` file generated as a result of the expression `'a'*10**10`). [Here's](https://github.com/python/cpython/blob/3.6/Python/peephole.c#L288) the implementation source for the same.
-
---
### ▶ Time for some hash brownies!
@@ -248,7 +247,7 @@ some_dict[5] = "Python"
---
-### ▶ Return return everywhere!
+### ▶ Keep trying? *
```py
def some_func():
@@ -256,18 +255,55 @@ def some_func():
return 'from_try'
finally:
return 'from_finally'
+
+def another_func():
+ for _ in range(3):
+ try:
+ continue
+ finally:
+ print("Finally!")
+
+def one_more_func(): # A gotcha!
+ try:
+ for i in range(3):
+ try:
+ 1 / i
+ except ZeroDivisionError:
+ # Let's throw it here and handle it outside for loop
+ raise ZeroDivisionError("A trivial divide by zero error")
+ finally:
+ print("Iteration", i)
+ break
+ except ZeroDivisionError as e:
+ print("Zero division error ocurred", e)
```
**Output:**
+
```py
>>> some_func()
'from_finally'
+
+>>> another_func()
+Finally!
+Finally!
+Finally!
+
+>>> 1 / 0
+Traceback (most recent call last):
+ File "", line 1, in
+ZeroDivisionError: division by zero
+
+>>> one_more_func()
+Iteration 0
+
```
#### 💡 Explanation:
- When a `return`, `break` or `continue` statement is executed in the `try` suite of a "try…finally" statement, the `finally` clause is also executed ‘on the way out.
- The return value of a function is determined by the last `return` statement executed. Since the `finally` clause always executes, a `return` statement executed in the `finally` clause will always be the last one executed.
+- The caveat here is, if the finally clause executes a `return` or `break` statement, the temporarily saved exception is discarded.
---
@@ -531,11 +567,11 @@ We didn't assign 3 "X"s or did we?
When we initialize `row` variable, this visualization explains what happens in the memory
-![image](/images/tic-tac-toe/after_row_initialized.png)
+![image](images/tic-tac-toe/after_row_initialized.png)
And when the `board` is initialized by multiplying the `row`, this is what happens inside the memory (each of the elements `board[0]`, `board[1]` and `board[2]` is a reference to the same list referred by `row`)
-![image](/images/tic-tac-toe/after_board_initialized.png)
+![image](images/tic-tac-toe/after_board_initialized.png)
We can avoid this scenario here by not using `row` variable to generate `board`. (Asked in [this](https://github.com/satwikkansal/wtfpython/issues/68) issue).
@@ -1185,8 +1221,9 @@ a, b = a[b] = {}, 5
(target_list "=")+ (expression_list | yield_expression)
```
and
- > An assignment statement evaluates the expression list (remember that this can be a single expression or a comma-separated list, the latter yielding a tuple) and assigns the single resulting object to each of the target lists, from left to right.
-
+
+> An assignment statement evaluates the expression list (remember that this can be a single expression or a comma-separated list, the latter yielding a tuple) and assigns the single resulting object to each of the target lists, from left to right.
+
* The `+` in `(target_list "=")+` means there can be **one or more** target lists. In this case, target lists are `a, b` and `a[b]` (note the expression list is exactly one, which in our case is `{}, 5`).
* After the expression list is evaluated, it's value is unpacked to the target lists from **left to right**. So, in our case, first the `{}, 5` tuple is unpacked to `a, b` and we now have `a = {}` and `b = 5`.
@@ -1320,6 +1357,7 @@ Shouldn't that be 100?
* **Don't mix tabs and spaces!** The character just preceding return is a "tab", and the code is indented by multiple of "4 spaces" elsewhere in the example.
* This is how Python handles tabs:
+
> First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight <...>
* So the "tab" at the last line of `square` function is replaced with eight spaces, and it gets into the loop.
* Python 3 is kind enough to throw an error for such cases automatically.
@@ -2041,6 +2079,7 @@ There we go.
#### 💡 Explanation:
- This is relevant to [PEP-401](https://www.python.org/dev/peps/pep-0401/) released on April 1, 2009 (now you know, what it means).
- Quoting from the PEP-401
+
> Recognized that the != inequality operator in Python 3.0 was a horrible, finger pain inducing mistake, the FLUFL reinstates the <> diamond operator as the sole spelling.
- There were more things that Uncle Barry had to share in the PEP; you can read them [here](https://www.python.org/dev/peps/pep-0401/).