<!-- START doctoc generated TOC please keep comment here to allow auto update -->

<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->

- [Structure of the Examples](#structure-of-the-examples)

- [Usage](#usage)

- [👀 Examples](#-examples)

- [Section: Strain your brain!](#section-strain-your-brain)

- [▶ Strings can be tricky sometimes *](#-strings-can-be-tricky-sometimes-)

- [▶ Time for some hash brownies!](#-time-for-some-hash-brownies)

- [▶ Return return everywhere!](#-return-return-everywhere)

- [▶ Deep down, we're all the same. *](#-deep-down-were-all-the-same-)

- [▶ For what?](#-for-what)

- [▶ Evaluation time discrepancy](#-evaluation-time-discrepancy)

- [▶ `is` is not what it is!](#-is-is-not-what-it-is)

- [▶ A tic-tac-toe where X wins in the first attempt!](#-a-tic-tac-toe-where-x-wins-in-the-first-attempt)

- [▶ The sticky output function](#-the-sticky-output-function)

- [▶ `is not ...` is not `is (not ...)`](#-is-not--is-not-is-not-)

- [▶ The surprising comma](#-the-surprising-comma)

- [▶ Backslashes at the end of string](#-backslashes-at-the-end-of-string)

- [▶ not knot!](#-not-knot)

- [▶ Half triple-quoted strings](#-half-triple-quoted-strings)

- [▶ Midnight time doesn't exist?](#-midnight-time-doesnt-exist)

- [▶ What's wrong with booleans?](#-whats-wrong-with-booleans)

- [▶ Class attributes and instance attributes](#-class-attributes-and-instance-attributes)

- [▶ yielding None](#-yielding-none)

- [▶ Mutating the immutable!](#-mutating-the-immutable)

- [▶ The disappearing variable from outer scope](#-the-disappearing-variable-from-outer-scope)

- [▶ When True is actually False](#-when-true-is-actually-false)

- [▶ From filled to None in one instruction...](#-from-filled-to-none-in-one-instruction)

- [▶ Subclass relationships *](#-subclass-relationships-)

- [▶ The mysterious key type conversion *](#-the-mysterious-key-type-conversion-)

- [▶ Let's see if you can guess this?](#-lets-see-if-you-can-guess-this)

- [Section: Appearances are deceptive!](#section-appearances-are-deceptive)

- [▶ Skipping lines?](#-skipping-lines)

- [▶ Teleportation *](#-teleportation-)

- [▶ Well, something is fishy...](#-well-something-is-fishy)

- [Section: Watch out for the landmines!](#section-watch-out-for-the-landmines)

- [▶ Modifying a dictionary while iterating over it](#-modifying-a-dictionary-while-iterating-over-it)

- [▶ Stubborn `del` operator *](#-stubborn-del-operator-)

- [▶ Deleting a list item while iterating](#-deleting-a-list-item-while-iterating)

- [▶ Loop variables leaking out!](#-loop-variables-leaking-out)

- [▶ Beware of default mutable arguments!](#-beware-of-default-mutable-arguments)

- [▶ Catching the Exceptions](#-catching-the-exceptions)

- [▶ Same operands, different story!](#-same-operands-different-story)

- [▶ The out of scope variable](#-the-out-of-scope-variable)

- [▶ Be careful with chained operations](#-be-careful-with-chained-operations)

- [▶ Name resolution ignoring class scope](#-name-resolution-ignoring-class-scope)

- [▶ Needle in a Haystack](#-needle-in-a-haystack)

- [Section: The Hidden treasures!](#section-the-hidden-treasures)

- [▶ Okay Python, Can you make me fly? *](#-okay-python-can-you-make-me-fly-)

- [▶ `goto`, but why? *](#-goto-but-why-)

- [▶ Brace yourself! *](#-brace-yourself-)

- [▶ Let's meet Friendly Language Uncle For Life *](#-lets-meet-friendly-language-uncle-for-life-)

- [▶ Even Python understands that love is complicated *](#-even-python-understands-that-love-is-complicated-)

- [▶ Yes, it exists!](#-yes-it-exists)

- [▶ Inpinity *](#-inpinity-)

- [▶ Mangling time! *](#-mangling-time-)

- [Section: Miscellaneous](#section-miscellaneous)

- [▶ `+=` is faster](#--is-faster)

- [▶ Let's make a giant string!](#-lets-make-a-giant-string)

- [▶ Explicit typecast of strings](#-explicit-typecast-of-strings)

- [▶ Minor Ones](#-minor-ones)

- [Contributing](#contributing)

- [Acknowledgements](#acknowledgements)

- [🎓 License](#-license)

- [Help](#help)

- [Want to share wtfpython with friends?](#want-to-share-wtfpython-with-friends)

- [Need a pdf version?](#need-a-pdf-version)

<!-- END doctoc generated TOC please keep comment here to allow auto update -->

All the examples are structured like below:

> ### ▶ Some fancy Title *

> The asterisk at the end of the title indicates the example was not present in the first release and has been recently added.

> ```py

> # Setting up the code.

> # Preparation for the magic...

> ```

> **Output (Python version):**

> ```py

> >>> triggering_statement

> Probably unexpected output

> ```

> (Optional): One line describing the unexpected output.

> #### 💡 Explanation:

> * Brief explanation of what's happening and why is it happening.

> ```py

> Setting up examples for clarification (if necessary)

> ```

> **Output:**

> ```py

> >>> trigger # some example that makes it easy to unveil the magic

> # some justified output

> ```

**Note:** All the examples are tested on Python 3.5.2 interactive interpreter, and they should work for all the Python versions unless explicitly specified in the description.

A nice way to get the most out of these examples, in my opinion, will be just to read the examples chronologically, and for every example:

- Carefully read the initial code for setting up the example. If you're an experienced Python programmer, most of the times you will successfully anticipate what's going to happen next.

- Read the output snippets and,

+ Check if the outputs are the same as you'd expect.

+ Make sure if you know the exact reason behind the output being the way it is.

- If no, take a deep breath, and read the explanation (and if you still don't understand, shout out! and create an issue [here](https://github.com/satwikkansal/wtfPython)).

- If yes, give a gentle pat on your back, and you may skip to the next example.

PS: You can also read WTFpython at the command line. There's a pypi package and an npm package (supports colored formatting) for the same.

To install the npm package [`wtfpython`](https://www.npmjs.com/package/wtfpython)

```sh

$ npm install -g wtfpython

```

Alternatively, to install the pypi package [`wtfpython`](https://pypi.python.org/pypi/wtfpython)

```sh

$ pip install wtfpython -U

```

Now, just run `wtfpython` at the command line which will open this collection in your selected `$PAGER`.

1\.

```py

>>> a = "some_string"

>>> id(a)

>>> id("some" + "_" + "string") # Notice that both the ids are same.

```

2\.

```py

>>> a = "wtf"

>>> b = "wtf"

>>> a is b

>>> a = "wtf!"

>>> b = "wtf!"

>>> a is b

>>> a, b = "wtf!", "wtf!"

>>> a is b

```

3\.

```py

>>> 'a' * 20 is 'aaaaaaaaaaaaaaaaaaaa'

>>> 'a' * 21 is 'aaaaaaaaaaaaaaaaaaaaa'

```

Makes sense, right?

+ Such behavior is due to CPython optimization (called string interning) that tries to use existing immutable objects in some cases rather than creating a new object every time.

+ After being interned, many variables may point to the same string object in memory (thereby saving memory).

+ In the snippets above, strings are implicitly interned. The decision of when to implicitly intern a string is implementation dependent. There are some facts that can be used to guess if a string will be interned or not:

* 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="">

+ 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 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.

1\.

```py

some_dict = {}

some_dict[5.5] = "Ruby"

some_dict[5.0] = "JavaScript"

some_dict[5] = "Python"

```

**Output:**

```py

>>> some_dict[5.5]

>>> some_dict[5.0]

>>> some_dict[5]

"Python" destroyed the existence of "JavaScript"?

* Python dictionaries check for equality and compare the hash value to determine if two keys are the same.

* Immutable objects with same value always have the same hash in Python.

```py

>>> 5 == 5.0

True

>>> hash(5) == hash(5.0)

True

```

**Note:** Objects with different values may also have same hash (known as hash collision).

* When the statement `some_dict[5] = "Python"` is executed, the existing value "JavaScript" is overwritten with "Python" because Python recognizes `5` and `5.0` as the same keys of the dictionary `some_dict`.

* This StackOverflow [answer](https://stackoverflow.com/a/32211042/4354153) explains beautifully the rationale behind it.

```py

def some_func():

try:

return 'from_try'

finally:

return 'from_finally'

```

**Output:**

```py

>>> some_func()

```

- 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.

```py

class WTF:

pass

```

**Output:**

```py

>>> WTF() == WTF() # two different instances can't be equal

>>> WTF() is WTF() # identities are also different

>>> hash(WTF()) == hash(WTF()) # hashes _should_ be different as well

>>> id(WTF()) == id(WTF())

```

* When `id` was called, Python created a `WTF` class object and passed it to the `id` function. The `id` function takes its `id` (its memory location), and throws away the object. The object is destroyed.

* When we do this twice in succession, Python allocates the same memory location to this second object as well. Since (in CPython) `id` uses the memory location as the object id, the id of the two objects is the same.

* So, object's id is unique only for the lifetime of the object. After the object is destroyed, or before it is created, something else can have the same id.

* But why did the `is` operator evaluated to `False`? Let's see with this snippet.

```py

class WTF(object):

def __init__(self): print("I")

def __del__(self): print("D")

```

**Output:**

```py

>>> WTF() is WTF()

I

I

D

D

False

>>> id(WTF()) == id(WTF())

I

D

I

D

True

```

As you may observe, the order in which the objects are destroyed is what made all the difference here.

```py

some_string = "wtf"

some_dict = {}

for i, some_dict[i] in enumerate(some_string):

pass

```

**Output:**

```py

>>> some_dict # An indexed dict is created.

{0: 'w', 1: 't', 2: 'f'}

```

* A `for` statement is defined in the [Python grammar](https://docs.python.org/3/reference/grammar.html) as:

```

for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite]

```

Where `exprlist` is the assignment target. This means that the equivalent of `{exprlist} = {next_value}` is **executed for each item** in the iterable.

An interesting example that illustrates this:

```py

for i in range(4):

print(i)

i = 10

```

**Output:**

```

0

1

2

3

```

Did you expect the loop to run just once?

**💡 Explanation:**

- The assignment statement `i = 10` never affects the iterations of the loop because of the way for loops work in Python. Before the beginning of every iteration, the next item provided by the iterator (`range(4)` this case) is unpacked and assigned the target list variables (`i` in this case).

* The `enumerate(some_string)` function yields a new value `i` (A counter going up) and a character from the `some_string` in each iteration. It then sets the (just assigned) `i` key of the dictionary `some_dict` to that character. The unrolling of the loop can be simplified as:

```py

>>> i, some_dict[i] = (0, 'w')

>>> i, some_dict[i] = (1, 't')

>>> i, some_dict[i] = (2, 'f')

>>> some_dict

```

1\.

```py

array = [1, 8, 15]

g = (x for x in array if array.count(x) > 0)

array = [2, 8, 22]

```

**Output:**

```py

>>> print(list(g))

[8]

```

2\.

```py

array_1 = [1,2,3,4]

g1 = (x for x in array_1)

array_1 = [1,2,3,4,5]

array_2 = [1,2,3,4]

g2 = (x for x in array_2)

array_2[:] = [1,2,3,4,5]

```

**Output:**

```py

>>> print(list(g1))

[1,2,3,4]

>>> print(list(g2))

[1,2,3,4,5]

```

- In a [generator](https://wiki.python.org/moin/Generators) expression, the `in` clause is evaluated at declaration time, but the conditional clause is evaluated at runtime.

- So before runtime, `array` is re-assigned to the list `[2, 8, 22]`, and since out of `1`, `8` and `15`, only the count of `8` is greater than `0`, the generator only yields `8`.

- The differences in the output of `g1` and `g2` in the second part is due the way variables `array_1` and `array_2` are re-assigned values.

- In the first case, `array_1` is binded to the new object `[1,2,3,4,5]` and since the `in` clause is evaluated at the declaration time it still refers to the old object `[1,2,3,4]` (which is not destroyed).

- In the second case, the slice assignment to `array_2` updates the same old object `[1,2,3,4]` to `[1,2,3,4,5]`. Hence both the `g2` and `array_2` still have reference to the same object (which has now been updated to `[1,2,3,4,5]`).

The following is a very famous example present all over the internet.

```py

>>> a = 256

>>> b = 256

>>> a is b

>>> a = 257

>>> b = 257

>>> a is b

>>> a = 257; b = 257

>>> a is b

```

**The difference between `is` and `==`**

* `is` operator checks if both the operands refer to the same object (i.e., it checks if the identity of the operands matches or not).

* `==` operator compares the values of both the operands and checks if they are the same.

* So `is` is for reference equality and `==` is for value equality. An example to clear things up,

```py

>>> [] == []

True

>>> [] is [] # These are two empty lists at two different memory locations.

False

```

**`256` is an existing object but `257` isn't**

When you start up python the numbers from `-5` to `256` will be allocated. These numbers are used a lot, so it makes sense just to have them ready.

Quoting from https://docs.python.org/3/c-api/long.html

> The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you just get back a reference to the existing object. So it should be possible to change the value of 1. I suspect the behavior of Python, in this case, is undefined. :-)

```py

>>> id(256)

>>> a = 256

>>> b = 256

>>> id(a)

>>> id(b)

>>> id(257)

>>> x = 257

>>> y = 257

>>> id(x)

>>> id(y)

```

Here the interpreter isn't smart enough while executing `y = 257` to recognize that we've already created an integer of the value `257,` and so it goes on to create another object in the memory.

**Both `a` and `b` refer to the same object when initialized with same value in the same line.**

```py

>>> a, b = 257, 257

>>> id(a)

>>> id(b)

>>> a = 257

>>> b = 257

>>> id(a)

>>> id(b)

```

* When a and b are set to `257` 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 `257` as an object.

* It's a compiler optimization and specifically applies to the interactive environment. When you enter two lines in a live interpreter, they're compiled separately, therefore optimized separately. If you were to try this example in a `.py` file, you would not see the same behavior, because the file is compiled all at once.

```py

row = [""]*3 #row i['', '', '']

board = [row]*3

```

**Output:**

```py

>>> board

[['', '', ''], ['', '', ''], ['', '', '']]

>>> board[0]

['', '', '']

>>> board[0][0]

>>> board[0][0] = "X"

>>> board

[['X', '', ''], ['X', '', ''], ['X', '', '']]

```

We didn't assign 3 "X"s or did we?

When we initialize `row` variable, this visualization explains what happens in the memory


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`)


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).

```py

>>> board = [['']*3 for _ in range(3)]

>>> board[0][0] = "X"

>>> board

[['X', '', ''], ['', '', ''], ['', '', '']]

```

```py

funcs = []

results = []

for x in range(7):

def some_func():

return x

funcs.append(some_func)

results.append(some_func())

funcs_results = [func() for func in funcs]

```

**Output:**

```py

>>> results

[0, 1, 2, 3, 4, 5, 6]

>>> funcs_results

[6, 6, 6, 6, 6, 6, 6]

Even when the values of `x` were different in every iteration prior to appending `some_func` to `funcs`, all the functions return 6.

```py

>>> powers_of_x = [lambda x: x**i for i in range(10)]

>>> [f(2) for f in powers_of_x]

[512, 512, 512, 512, 512, 512, 512, 512, 512, 512]

```

- When defining a function inside a loop that uses the loop variable in its body, the loop function's closure is bound to the variable, not its value. So all of the functions use the latest value assigned to the variable for computation.

- To get the desired behavior you can pass in the loop variable as a named variable to the function. **Why this works?** Because this will define the variable again within the function's scope.

```py

funcs = []

for x in range(7):

def some_func(x=x):

return x

funcs.append(some_func)

```

**Output:**

```py

>>> funcs_results = [func() for func in funcs]

>>> funcs_results

[0, 1, 2, 3, 4, 5, 6]

```

```py

>>> 'something' is not None

>>> 'something' is (not None)

```

- `is not` is a single binary operator, and has behavior different than using `is` and `not` separated.

- `is not` evaluates to `False` if the variables on either side of the operator point to the same object and `True` otherwise.

**Output:**

```py

>>> def f(x, y,):

... print(x, y)

...

>>> def g(x=4, y=5,):

... print(x, y)

...

>>> def h(x, **kwargs,):

File "<stdin>", line 1

def h(x, **kwargs,):

^

SyntaxError: invalid syntax

>>> def h(*args,):

File "<stdin>", line 1

def h(*args,):

^

SyntaxError: invalid syntax

```

- Trailing comma is not always legal in formal parameters list of a Python function.

- In Python, the argument list is defined partially with leading commas and partially with trailing commas. This conflict causes situations where a comma is trapped in the middle, and no rule accepts it.

- **Note:** The trailing comma problem is [fixed in Python 3.6](https://bugs.python.org/issue9232). The remarks in [this](https://bugs.python.org/issue9232#msg248399) post discuss in brief different usages of trailing commas in Python.

**Output:**

>>> print(r"\ C:")

\ C:

>>> print(r"\ C:\")

File "<stdin>", line 1

print(r"\ C:\")

^

SyntaxError: EOL while scanning string literal

```

- In a raw string literal, as indicated by the prefix `r`, the backslash doesn't have the special meaning.

```py

>>> print(repr(r"wt\"f"))

'wt\\"f'

```

- What the interpreter actually does, though, is simply change the behavior of backslashes, so they pass themselves and the following character through. That's why backslashes don't work at the end of a raw string.

```py

x = True

y = False

```

**Output:**

```py

>>> not x == y

>>> x == not y

File "<input>", line 1

x == not y

^

SyntaxError: invalid syntax

```

* Operator precedence affects how an expression is evaluated, and `==` operator has higher precedence than `not` operator in Python.

* So `not x == y` is equivalent to `not (x == y)` which is equivalent to `not (True == False)` finally evaluating to `True`.

* But `x == not y` raises a `SyntaxError` because it can be thought of being equivalent to `(x == not) y` and not `x == (not y)` which you might have expected at first sight.

* The parser expected the `not` token to be a part of the `not in` operator (because both `==` and `not in` operators have the same precedence), but after not being able to find an `in` token following the `not` token, it raises a `SyntaxError`.

**Output:**

```py

>>> print('wtfpython''')

>>> print("wtfpython""")

>>> # The following statements raise `SyntaxError`

>>> # print('''wtfpython')

>>> # print("""wtfpython")

```

+ Python supports implicit [string literal concatenation](https://docs.python.org/2/reference/lexical_analysis.html#string-literal-concatenation), Example,

```

>>> print("wtf" "python")

wtfpython

>>> print("wtf" "") # or "wtf"""

wtf

```

+ `'''` and `"""` are also string delimiters in Python which causes a SyntaxError because the Python interpreter was expecting a terminating triple quote as delimiter while scanning the currently encountered triple quoted string literal.

---

### ▶ Midnight time doesn't exist?

```py

from datetime import datetime

midnight = datetime(2018, 1, 1, 0, 0)

midnight_time = midnight.time()

noon = datetime(2018, 1, 1, 12, 0)

noon_time = noon.time()

if midnight_time:

print("Time at midnight is", midnight_time)

if noon_time:

print("Time at noon is", noon_time)

```

**Output:**

```sh

('Time at noon is', datetime.time(12, 0))

```

The midnight time is not printed.

#### 💡 Explanation:

Before Python 3.5, the boolean value for `datetime.time` object was considered to be `False` if it represented midnight in UTC. It is error-prone when using the `if obj:` syntax to check if the `obj` is null or some equivalent of "empty."

---

### ▶ What's wrong with booleans?

1\.

```py

# A simple example to count the number of boolean and

# integers in an iterable of mixed data types.

mixed_list = [False, 1.0, "some_string", 3, True, [], False]

integers_found_so_far = 0

booleans_found_so_far = 0

for item in mixed_list:

if isinstance(item, int):

integers_found_so_far += 1

elif isinstance(item, bool):

booleans_found_so_far += 1

```

**Output:**

```py

>>> booleans_found_so_far

0

>>> integers_found_so_far

4

```

2\.

```py

another_dict = {}

another_dict[True] = "JavaScript"

another_dict[1] = "Ruby"

another_dict[1.0] = "Python"

```

**Output:**

```py

>>> another_dict[True]

"Python"

```

3\.

```py

>>> some_bool = True

>>> "wtf"*some_bool

'wtf'

>>> some_bool = False

>>> "wtf"*some_bool

''

```

#### 💡 Explanation:

* Booleans are a subclass of `int`

```py

>>> isinstance(True, int)

True

>>> isinstance(False, int)

True

```

* The integer value of `True` is `1` and that of `False` is `0`.

```py

>>> True == 1 == 1.0 and False == 0 == 0.0

True

```

* See this StackOverflow [answer](https://stackoverflow.com/a/8169049/4354153) for the rationale behind it.

---

### ▶ Class attributes and instance attributes

1\.

```py

class A:

x = 1

class B(A):

pass

class C(A):

pass

```

**Ouptut:**

```py