<!-- Generated using "markdown-toc -i README.md --maxdepth 3"-->

<!-- toc -->

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

+ [▶ Some fancy Title](#-some-fancy-title)

- [Usage](#usage)

- [👀 Examples](#-examples)

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

+ [▶ First things first! *](#-first-things-first-)

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

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

+ [▶ How not to use `is` operator](#-how-not-to-use-is-operator)

+ [▶ Hash brownies](#-hash-brownies)

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

+ [▶ Disorder within order *](#-disorder-within-order-)

+ [▶ Keep trying... *](#-keep-trying-)

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

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

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

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

+ [▶ Schrödinger's variable](#-schrödingers-variable-)

+ [▶ The chicken-egg problem *](#-the-chicken-egg-problem-)

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

+ [▶ Methods equality and identity](#-methods-equality-and-identity)

+ [▶ All-true-ation *](#-all-true-ation-)

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

+ [▶ Strings and the backslashes](#-strings-and-the-backslashes)

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

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

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

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

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

+ [▶ Yielding from... return! *](#-yielding-from-return-)

+ [▶ Nan-reflexivity *](#-nan-reflexivity-)

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

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

+ [▶ 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: Slippery Slopes](#section-slippery-slopes)

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

+ [▶ Stubborn `del` operation](#-stubborn-del-operation)

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

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

+ [▶ Lossy zip of iterators *](#-lossy-zip-of-iterators-)

+ [▶ 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)

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

+ [▶ Needles in a Haystack *](#-needles-in-a-haystack-)

+ [▶ Splitsies *](#-splitsies-)

+ [▶ Wild imports *](#-wild-imports-)

+ [▶ All sorted? *](#-all-sorted-)

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

* [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)

+ [▶ Ellipsis *](#-ellipsis-)

+ [▶ Inpinity](#-inpinity)

+ [▶ Let's mangle](#-lets-mangle)

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

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

+ [▶ Teleportation](#-teleportation)

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

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

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

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

+ [▶ Slowing down `dict` lookups *](#-slowing-down-dict-lookups-)

+ [▶ Bloating instance `dict`s *](#-bloating-instance-dicts-)

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

- [Contributing](#contributing)

- [Acknowledgements](#acknowledgements)

- [🎓 License](#-license)

* [Surprise your friends as well!](#surprise-your-friends-as-well)

* [More content like this?](#more-content-like-this)

<!-- tocstop -->

All the examples are structured like below:

> ### ▶ Some fancy Title

> ```py

> # Set up the code.

> # Preparation for the magic...

> ```

> **Output (Python version(s)):**

> ```py

> >>> triggering_statement

> Some unexpected output

> ```

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

> #### 💡 Explanation:

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

> ```py

> # Set up code

> # More examples for further clarification (if necessary)

> ```

> **Output (Python version(s)):**

> ```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 before the output.

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

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

- 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 the answer is no (which is perfectly okay), 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/issues/new)).

- 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 using the [pypi package](https://pypi.python.org/pypi/wtfpython),

```sh

$ pip install wtfpython -U

$ wtfpython

```

<!-- Example ID: d3d73936-3cf1-4632-b5ab-817981338863 -->

<!-- read-only -->

For some reason, the Python 3.8's "Walrus" operator (`:=`) has become quite popular. Let's check it out,

1\.

```py

>>> a = "wtf_walrus"

>>> a

>>> a := "wtf_walrus"

File "<stdin>", line 1

a := "wtf_walrus"

^

SyntaxError: invalid syntax

>>> (a := "wtf_walrus") # This works though

>>> a

```

2 \.

```py

>>> a = 6, 9

>>> a

(6, 9)

>>> (a := 6, 9)

(6, 9)

>>> a

>>> a, b = 6, 9 # Typical unpacking

>>> a, b

(6, 9)

>>> (a, b = 16, 19) # Oops

File "<stdin>", line 1

(a, b = 6, 9)

^

SyntaxError: invalid syntax

>>> (a, b := 16, 19) # This prints out a weird 3-tuple

(6, 16, 19)

>>> a # a is still unchanged?

>>> b

```

**Quick walrus operator refresher**

The Walrus operator (`:=`) was introduced in Python 3.8, it can be useful in situations where you'd want to assign values to variables within an expression.

```py

def some_func():

# Assume some expensive computation here

# time.sleep(1000)

return 5

if some_func():

print(some_func()) # Which is bad practice since computation is happening twice

a = some_func()

if a:

print(a)

if a := some_func():

print(a)

```

**Output (> 3.8):**

```py

```

This saved one line of code, and implicitly prevented invoking `some_func` twice.

- Unparenthesized "assignment expression" (use of walrus operator), is restricted at the top level, hence the `SyntaxError` in the `a := "wtf_walrus"` statement of the first snippet. Parenthesizing it worked as expected and assigned `a`.

- As usual, parenthesizing of an expression containing `=` operator is not allowed. Hence the syntax error in `(a, b = 6, 9)`.

- The syntax of the Walrus operator is of the form `NAME:= expr`, where `NAME` is a valid identifier, and `expr` is a valid expression. Hence, iterable packing and unpacking are not supported which means,

- `(a := 6, 9)` is equivalent to `((a := 6), 9)` and ultimately `(a, 9) ` (where `a`'s value is 6')

```py

>>> (a := 6, 9) == ((a := 6), 9)

True

>>> x = (a := 696, 9)

>>> x

(696, 9)

>>> x[0] is a # Both reference same memory location

True

```

- Similarly, `(a, b := 16, 19)` is equivalent to `(a, (b := 16), 19)` which is nothing but a 3-tuple.

<!-- Example ID: 30f1d3fc-e267-4b30-84ef-4d9e7091ac1a --->

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

```

3\.

```py

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

>>> a is b # All versions except 3.7.x

>>> a = "wtf!"; b = "wtf!"

>>> a is b # This will print True or False depending on where you're invoking it (python shell / ipython / as a script)

```

```py

a = "wtf!"

b = "wtf!"

print(a is b)

```

4\.

**Output (< Python3.7 )**

```py

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

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

```

Makes sense, right?

+ The behavior in first and second snippets is due to a 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 reference the same string object in memory (saving memory thereby).

+ In the snippets above, strings are implicitly interned. The decision of when to implicitly intern a string is implementation-dependent. There are some rules 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)


+ 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 compile-time optimization. This optimization doesn't apply to 3.7.x versions of CPython (check this [issue](https://github.com/satwikkansal/wtfpython/issues/100) for more discussion).

+ A compile unit in an interactive environment like IPython consists of a single statement, whereas it consists of the entire module in case of modules. `a, b = "wtf!", "wtf!"` is single statement, whereas `a = "wtf!"; b = "wtf!"` are two statements in a single line. This explains why the identities are different in `a = "wtf!"; b = "wtf!"`, and also explain why they are same when invoked in `some_file.py`

+ The abrupt change in the output of the fourth snippet is due to a [peephole optimization](https://en.wikipedia.org/wiki/Peephole_optimization) technique known as Constant folding. This means the expression `'a'*20` is replaced by `'aaaaaaaaaaaaaaaaaaaa'` during compilation to save a few clock cycles during runtime. Constant folding only occurs for strings having a length of less than 21. (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.

+ Note: In Python 3.7, Constant folding was moved out from peephole optimizer to the new AST optimizer with some change in logic as well, so the fourth snippet doesn't work for Python 3.7. You can read more about the change [here](https://bugs.python.org/issue11549).

<!-- Example ID: 07974979-9c86-4720-80bd-467aa19470d9 --->

```py

>>> (False == False) in [False] # makes sense

>>> False == (False in [False]) # makes sense

>>> False == False in [False] # now what?

>>> True is False == False

>>> False is False is False

>>> 1 > 0 < 1

>>> (1 > 0) < 1

>>> 1 > (0 < 1)

```

As per https://docs.python.org/3/reference/expressions.html#membership-test-operations

> Formally, if a, b, c, ..., y, z are expressions and op1, op2, ..., opN are comparison operators, then a op1 b op2 c ... y opN z is equivalent to a op1 b and b op2 c and ... y opN z, except that each expression is evaluated at most once.

While such behavior might seem silly to you in the above examples, it's fantastic with stuff like `a == b == c` and `0 <= x <= 100`.

* `False is False is False` is equivalent to `(False is False) and (False is False)`

* `True is False == False` is equivalent to `True is False and False == False` and since the first part of the statement (`True is False`) evaluates to `False`, the overall expression evaluates to `False`.

* `1 > 0 < 1` is equivalent to `1 > 0 and 0 < 1` which evaluates to `True`.

* The expression `(1 > 0) < 1` is equivalent to `True < 1` and

```py

>>> int(True)

1

>>> True + 1 #not relevant for this example, but just for fun

2

```

So, `1 < 1` evaluates to `False`

<!-- Example ID: 230fa2ac-ab36-4ad1-b675-5f5a1c1a6217 --->

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

1\.

```py

>>> a = 256

>>> b = 256

>>> a is b

>>> a = 257

>>> b = 257

>>> a is b

```

2\.

```py

>>> a = []

>>> b = []

>>> a is b

>>> a = tuple()

>>> b = tuple()

>>> a is b

```

3\.

```py

>>> a, b = 257, 257

>>> a is b

```

**Output (Python 3.7.x specifically)**

```py

>>> a, b = 257, 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

>>> class A: pass

>>> A() is A() # These are two empty objects 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.

Similar optimization applies to other **immutable** objects like empty tuples as well. Since lists are mutable, that's why `[] is []` will return `False` and `() is ()` will return `True`. This explains our second snippet. Let's move on to the third one,

**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. This optimization is not limited to integers, it works for other immutable data types like strings (check the "Strings are tricky example") and floats as well,

```py

>>> a, b = 257.0, 257.0

>>> a is b

True

```

* Why didn't this work for Python 3.7? The abstract reason is because such compiler optimizations are implementation specific (i.e. may change with version, OS, etc). I'm still figuring out what exact implementation change cause the issue, you can check out this [issue](https://github.com/satwikkansal/wtfpython/issues/100) for updates.

<!-- Example ID: eb17db53-49fd-4b61-85d6-345c5ca213ff --->

1\.

```py

some_dict = {}

some_dict[5.5] = "JavaScript"

some_dict[5.0] = "Ruby"

some_dict[5] = "Python"

```

**Output:**

```py

>>> some_dict[5.5]

>>> some_dict[5.0] # "Python" destroyed the existence of "Ruby"?

>>> some_dict[5]

>>> complex_five = 5 + 0j

>>> type(complex_five)

>>> some_dict[complex_five]

```

So, why is Python all over the place?

* Uniqueness of keys in a Python dictionary is by *equivalence*, not identity. So even though `5`, `5.0`, and `5 + 0j` are distinct objects of different types, since they're equal, they can't both be in the same `dict` (or `set`). As soon as you insert any one of them, attempting to look up any distinct but equivalent key will succeed with the original mapped value (rather than failing with a `KeyError`):

```py

>>> 5 == 5.0 == 5 + 0j

True

>>> 5 is not 5.0 is not 5 + 0j

True

>>> some_dict = {}

>>> some_dict[5.0] = "Ruby"

>>> 5.0 in some_dict

True

>>> (5 in some_dict) and (5 + 0j in some_dict)

True

```

* This applies when setting an item as well. So when you do `some_dict[5] = "Python"`, Python finds the existing item with equivalent key `5.0 -> "Ruby"`, overwrites its value in place, and leaves the original key alone.

```py

>>> some_dict

{5.0: 'Ruby'}

>>> some_dict[5] = "Python"

>>> some_dict

{5.0: 'Python'}

```

* So how can we update the key to `5` (instead of `5.0`)? We can't actually do this update in place, but what we can do is first delete the key (`del some_dict[5.0]`), and then set it (`some_dict[5]`) to get the integer `5` as the key instead of floating `5.0`, though this should be needed in rare cases.

* How did Python find `5` in a dictionary containing `5.0`? Python does this in constant time without having to scan through every item by using hash functions. When Python looks up a key `foo` in a dict, it first computes `hash(foo)` (which runs in constant-time). Since in Python it is required that objects that compare equal also have the same hash value ([docs](https://docs.python.org/3/reference/datamodel.html#object.__hash__) here), `5`, `5.0`, and `5 + 0j` have the same hash value.

```py

>>> 5 == 5.0 == 5 + 0j

True

>>> hash(5) == hash(5.0) == hash(5 + 0j)

True

```

**Note:** The inverse is not necessarily true: Objects with equal hash values may themselves be unequal. (This causes what's known as a [hash collision](https://en.wikipedia.org/wiki/Collision_(computer_science)), and degrades the constant-time performance that hashing usually provides.)

<!-- Example ID: 8f99a35f-1736-43e2-920d-3b78ec35da9b --->

```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, the 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.

<!-- Example ID: 91bff1f8-541d-455a-9de4-6cd8ff00ea66 --->

```py

from collections import OrderedDict

dictionary = dict()

dictionary[1] = 'a'; dictionary[2] = 'b';

ordered_dict = OrderedDict()

ordered_dict[1] = 'a'; ordered_dict[2] = 'b';

another_ordered_dict = OrderedDict()

another_ordered_dict[2] = 'b'; another_ordered_dict[1] = 'a';

class DictWithHash(dict):

"""

__hash__ = lambda self: 0

class OrderedDictWithHash(OrderedDict):

"""

__hash__ = lambda self: 0

```

```py

>>> dictionary == ordered_dict # If a == b

>>> dictionary == another_ordered_dict # and b == c

>>> ordered_dict == another_ordered_dict # then why isn't c == a ??

>>> len({dictionary, ordered_dict, another_ordered_dict})

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

TypeError: unhashable type: 'dict'

>>> dictionary = DictWithHash()

>>> dictionary[1] = 'a'; dictionary[2] = 'b';

>>> ordered_dict = OrderedDictWithHash()

>>> ordered_dict[1] = 'a'; ordered_dict[2] = 'b';

>>> another_ordered_dict = OrderedDictWithHash()

>>> another_ordered_dict[2] = 'b'; another_ordered_dict[1] = 'a';

>>> len({dictionary, ordered_dict, another_ordered_dict})

>>> len({ordered_dict, another_ordered_dict, dictionary}) # changing the order

```

What is going on here?

- The reason why intransitive equality didn't hold among `dictionary`, `ordered_dict` and `another_ordered_dict` is because of the way `__eq__` method is implemented in `OrderedDict` class. From the [docs](https://docs.python.org/3/library/collections.html#ordereddict-objects)

> Equality tests between OrderedDict objects are order-sensitive and are implemented as `list(od1.items())==list(od2.items())`. Equality tests between `OrderedDict` objects and other Mapping objects are order-insensitive like regular dictionaries.

- The reason for this equality in behavior is that it allows `OrderedDict` objects to be directly substituted anywhere a regular dictionary is used.

- Okay, so why did changing the order affect the length of the generated `set` object? The answer is the lack of intransitive equality only. Since sets are "unordered" collections of unique elements, the order in which elements are inserted shouldn't matter. But in this case, it does matter. Let's break it down a bit,

```py

>>> some_set = set()

>>> some_set.add(dictionary) # these are the mapping objects from the snippets above

>>> ordered_dict in some_set

True

>>> some_set.add(ordered_dict)

>>> len(some_set)

1

>>> another_ordered_dict in some_set

True

>>> some_set.add(another_ordered_dict)

>>> len(some_set)

1

>>> another_set = set()

>>> another_set.add(ordered_dict)

>>> another_ordered_dict in another_set

False

>>> another_set.add(another_ordered_dict)

>>> len(another_set)

2

>>> dictionary in another_set

True

>>> another_set.add(another_ordered_dict)

>>> len(another_set)

2

```

So the inconsistency is due to `another_ordered_dict in another_set` being `False` because `ordered_dict` was already present in `another_set` and as observed before, `ordered_dict == another_ordered_dict` is `False`.

<!-- Example ID: b4349443-e89f-4d25-a109-82616be9d41a --->

```py

def some_func():

try:

return 'from_try'

finally:

return 'from_finally'

def another_func():

for _ in range(3):

try:

continue

finally:

print("Finally!")