From 810dbe15822ff0393dd29746573bb950bc58220f Mon Sep 17 00:00:00 2001 From: Satwik Kansal Date: Fri, 7 Jun 2019 23:48:07 +0530 Subject: [PATCH] Some hideous typora corrections and a new snippets added Also closes https://github.com/satwikkansal/wtfpython/issues/73 --- README.md | 55 +++++++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 47 insertions(+), 8 deletions(-) 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/).