mirror of
https://github.com/satwikkansal/wtfpython.git
synced 2024-09-11 20:17:08 +03:00
Some hideous typora corrections and a new snippets added
Also closes https://github.com/satwikkansal/wtfpython/issues/73
This commit is contained in:
parent
a5e7cd7cf8
commit
810dbe1582
55
README.md
vendored
55
README.md
vendored
@ -1,4 +1,4 @@
|
||||
<p align="center"><img src="/images/logo.png" alt=""></p>
|
||||
<p align="center"><img src="images/logo.png" alt=""></p>
|
||||
<h1 align="center">What the f*ck Python! 🐍</h1>
|
||||
<p align="center">An interesting collection of surprising snippets and lesser-known Python features.</p>
|
||||
|
||||
@ -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)
|
||||
<img src="/images/string-intern/string_intern.png" alt="">
|
||||
<img src="images/string-intern/string_intern.png" alt="">
|
||||
+ 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 "<stdin>", line 1, in <module>
|
||||
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/).
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user