• 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,

>>> some_set = set()
  >>> some_set.add(dictionary) # these are the mapping objects from the snippets above
  >>> ordereddict in someset
  True
  >>> someset.add(ordereddict)
  >>> len(some_set)
  1
  >>> anotherordereddict in some_set
  True
  >>> someset.add(anotherordered_dict)
  >>> len(some_set)
  1
>>> another_set = set()   >>> anotherset.add(ordereddict)   >>> anotherordereddict in another_set   False   >>> anotherset.add(anotherordered_dict)   >>> len(another_set)   2   >>> dictionary in another_set   True   >>> anotherset.add(anotherordered_dict)   >>> len(another_set)   2

So the inconsistency is due to anotherordereddict in anotherset being False because ordereddict was already present in anotherset and as observed before, ordereddict == anotherordereddict is False.

▶ Keep trying... \*

def some_func():
    try:
        return 'from_try'
    finally:
        return 'from_finally'
def another_func():     for _ in range(3):         try:             continue         finally:             print("Finally!")
def onemorefunc(): # 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 occurred", e)

Output:

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

▶ For what?

some_string = "wtf"
some_dict = {}
for i, somedict[i] in enumerate(somestring):
    i = 10

Output:

>>> some_dict # An indexed dict appears.
{0: 'w', 1: 't', 2: 'f'}

💡 Explanation:

• A for statement is defined in the Python grammar 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:

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) in this case) is unpacked and assigned the target list variables (i in this case).

• The enumerate(somestring) function yields a new value i (a counter going up) and a character from the somestring 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:

>>> i, some_dict[i] = (0, 'w')
  >>> i, some_dict[i] = (1, 't')
  >>> i, some_dict[i] = (2, 'f')
  >>> some_dict

▶ Evaluation time discrepancy

1\.

array = [1, 8, 15]
A typical generator expression
gen = (x for x in array if array.count(x) > 0)
array = [2, 8, 22]

Output:

>>> print(list(gen)) # Where did the other values go?
[8]

2\.

array_1 = [1,2,3,4]
gen1 = (x for x in array1)
array_1 = [1,2,3,4,5]
array_2 = [1,2,3,4] gen2 = (x for x in array2) array_2[:] = [1,2,3,4,5]

Output:

>>> print(list(gen_1))
[1, 2, 3, 4]
>>> print(list(gen_2)) [1, 2, 3, 4, 5]

3\.

array_3 = [1, 2, 3]
array_4 = [10, 20, 30]
gen = (i + j for i in array3 for j in array4)
array_3 = [4, 5, 6] array_4 = [400, 500, 600]

Output:

>>> print(list(gen))
[401, 501, 601, 402, 502, 602, 403, 503, 603]

💡 Explanation

• In a generator 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 array1 and array2 are re-assigned values.
• In the first case, array_1 is bound 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 array2 updates the same old object [1,2,3,4] to [1,2,3,4,5]. Hence both the g2 and array2 still have reference to the same object (which has now been updated to [1,2,3,4,5]).
• Okay, going by the logic discussed so far, shouldn't be the value of list(gen) in the third snippet be [11, 21, 31, 12, 22, 32, 13, 23, 33]? (because array3 and array4 are going to behave just like array1). The reason why (only) array4 values got updated is explained in PEP-289

▶ is not ... is not is (not ...)

>>> 'something' is not None
True
>>> 'something' is (not None)
False

💡 Explanation

• 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.
• In the example, (not None) evaluates to True since the value None is False in a boolean context, so the expression becomes 'something' is True.

▶ A tic-tac-toe where X wins in the first attempt!

# Let's initialize a row
row = [""] * 3 #row i['', '', '']
Let's make a board
board = [row] * 3

Output:

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

We didn't assign three "X"s, did we?

💡 Explanation:

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

>>> board = [['']*3 for _ in range(3)]
>>> board[0][0] = "X"
>>> board
[['X', '', ''], ['', '', ''], ['', '', '']]

▶ Schrödinger's variable \*

funcs = []
results = []
for x in range(7):
    def some_func():
        return x
    funcs.append(some_func)
    results.append(some_func())  # note the function call here
funcs_results = [func() for func in funcs]

Output (Python version):

>>> results
[0, 1, 2, 3, 4, 5, 6]
>>> funcs_results
[6, 6, 6, 6, 6, 6, 6]

The values of x were different in every iteration prior to appending some_func to funcs, but all the functions return 6 when they're evaluated after the loop completes.

2.

>>> powersofx = [lambda x: x**i for i in range(10)]
>>> [f(2) for f in powersofx]
[512, 512, 512, 512, 512, 512, 512, 512, 512, 512]

💡 Explanation:

• When defining a function inside a loop that uses the loop variable in its body,

>>> import inspect
>>> inspect.getclosurevars(funcs[0])
ClosureVars(nonlocals={}, globals={'x': 6}, builtins={}, unbound=set())

Since x is a global value, we can change the value that the funcs will lookup and return by updating x:

>>> x = 42
>>> [func() for func in funcs]
[42, 42, 42, 42, 42, 42, 42]

• To get the desired behavior you can pass in the loop variable as a named variable to the function. Why does this work? Because this will define the variable inside the function's scope. It will no longer go to the surrounding (global) scope to look up the variables value but will create a local variable that stores the value of x at that point in time.

funcs = []
for x in range(7):
    def some_func(x=x):
        return x
    funcs.append(some_func)

Output:

>>> funcs_results = [func() for func in funcs]
>>> funcs_results
[0, 1, 2, 3, 4, 5, 6]

It is not longer using the x in the global scope:

>>> inspect.getclosurevars(funcs[0])
ClosureVars(nonlocals={}, globals={}, builtins={}, unbound=set())

▶ The chicken-egg problem \*

1\.

>>> isinstance(3, int)
True
>>> isinstance(type, object)
True
>>> isinstance(object, type)
True

So which is the "ultimate" base class? There's more to the confusion by the way,

2\.

>>> class A: pass
>>> isinstance(A, A)
False
>>> isinstance(type, type)
True
>>> isinstance(object, object)
True

3\.

>>> issubclass(int, object)
True
>>> issubclass(type, object)
True
>>> issubclass(object, type)
False

💡 Explanation

• type is a metaclass in Python.
• Everything is an object in Python, which includes classes as well as their objects (instances).
• class type is the metaclass of class object, and every class (including type) has inherited directly or indirectly from object.
• There is no real base class among object and type. The confusion in the above snippets is arising because we're thinking about these relationships (issubclass and isinstance) in terms of Python classes. The relationship between object and type can't be reproduced in pure python. To be more precise the following relationships can't be reproduced in pure Python,

• These relationships between object and type (both being instances of each other as well as themselves) exist in Python because of "cheating" at the implementation level.

▶ Subclass relationships

Output:

>>> from collections.abc import Hashable
>>> issubclass(list, object)
True
>>> issubclass(object, Hashable)
True
>>> issubclass(list, Hashable)
False

The Subclass relationships were expected to be transitive, right? (i.e., if A is a subclass of B, and B is a subclass of C, the A should a subclass of C)

💡 Explanation:

• Subclass relationships are not necessarily transitive in Python. Anyone is allowed to define their own, arbitrary subclasscheck in a metaclass.
• When issubclass(cls, Hashable) is called, it simply looks for non-Falsey "hash" method in cls or anything it inherits from.
• Since object is hashable, but list is non-hashable, it breaks the transitivity relation.
• More detailed explanation can be found here.

▶ Methods equality and identity

1.

class SomeClass:
    def method(self):
        pass
@classmethod     def classm(cls):         pass
@staticmethod     def staticm():         pass

Output:

>>> print(SomeClass.method is SomeClass.method)
True
>>> print(SomeClass.classm is SomeClass.classm)
False
>>> print(SomeClass.classm == SomeClass.classm)
True
>>> print(SomeClass.staticm is SomeClass.staticm)
True

Accessing classm twice, we get an equal object, but not the same one? Let's see what happens with instances of SomeClass:

2.

o1 = SomeClass()
o2 = SomeClass()

Output:

>>> print(o1.method == o2.method)
False
>>> print(o1.method == o1.method)
True
>>> print(o1.method is o1.method)
False
>>> print(o1.classm is o1.classm)
False
>>> print(o1.classm == o1.classm == o2.classm == SomeClass.classm)
True
>>> print(o1.staticm is o1.staticm is o2.staticm is SomeClass.staticm)
True

Accessing classm or method twice, creates equal but not same objects for the same instance of SomeClass.

💡 Explanation

• Functions are descriptors. Whenever a function is accessed as an

>>> o1.method
<bound method SomeClass.method of <main.SomeClass object at ...>>

• Accessing the attribute multiple times creates a method object every time! Therefore o1.method is o1.method is

>>> SomeClass.method
<function SomeClass.method at ...>

• classmethod transforms functions into class methods. Class methods are descriptors that, when accessed, create

>>> o1.classm
<bound method SomeClass.classm of <class 'main.SomeClass'>>

• Unlike functions, classmethods will create a method also when accessed as class attributes (in which case they

>>> SomeClass.classm
<bound method SomeClass.classm of <class 'main.SomeClass'>>

• A method object compares equal when both the functions are equal, and the bound objects are the same. So

• staticmethod transforms functions into a "no-op" descriptor, which returns the function as-is. No method

>>> o1.staticm
<function SomeClass.staticm at ...>
>>> SomeClass.staticm
<function SomeClass.staticm at ...>

• Having to create new "method" objects every time Python calls instance methods and having to modify the arguments

▶ All-true-ation \*

>>> all([True, True, True])
True
>>> all([True, True, False])
False
>>> all([]) True >>> all([[]]) False >>> all([[[]]]) True

Why's this True-False alteration?

💡 Explanation:

• The implementation of all function is equivalent to

• def all(iterable):

• all([]) returns True since the iterable is empty.
• all([[]]) returns False because the passed array has one element, [], and in python, an empty list is falsy.
• all([[[]]]) and higher recursive variants are always True. This is because the passed array's single element ([[...]]) is no longer empty, and lists with values are truthy.

▶ The surprising comma

Output (< 3.6):

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

💡 Explanation:

• 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. The remarks in this post discuss in brief different usages of trailing commas in Python.

▶ Strings and the backslashes

Output:

>>> print("\"")
"
>>> print(r"\"") \"
>>> print(r"\") File "<stdin>", line 1     print(r"\")               ^ SyntaxError: EOL while scanning string literal
>>> r'\'' == "\\'" True

💡 Explanation

• In a usual python string, the backslash is used to escape characters that may have a special meaning (like single-quote, double-quote, and the backslash itself).

>>> "wt\"f"
  'wt"f'

• In a raw string literal (as indicated by the prefix r), the backslashes pass themselves as is along with the behavior of escaping the following character.

>>> r'wt\"f' == 'wt\\"f'
  True
  >>> print(repr(r'wt\"f'))
  'wt\\"f'
>>> print("\n")
>>> print(r"\\n")   '\\n'

• This means when a parser encounters a backslash in a raw string, it expects another character following it. And in our case (print(r"\")), the backslash escaped the trailing quote, leaving the parser without a terminating quote (hence the SyntaxError). That's why backslashes don't work at the end of a raw string.

▶ not knot!

x = True
y = False

Output:

>>> not x == y
True
>>> x == not y
  File "<input>", line 1
    x == not y
           ^
SyntaxError: invalid syntax

💡 Explanation:

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

▶ Half triple-quoted strings

Output:

>>> print('wtfpython''')
wtfpython
>>> print("wtfpython""")
wtfpython
>>> # The following statements raise SyntaxError
>>> # print('''wtfpython')
>>> # print("""wtfpython")
  File "<input>", line 3
    print("""wtfpython")
                        ^
SyntaxError: EOF while scanning triple-quoted string literal

💡 Explanation:

• Python supports implicit 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.

▶ What's wrong with booleans?

1\.

# A simple example to count the number of booleans and
integers in an iterable of mixed data types.
mixedlist = [False, 1.0, "somestring", 3, True, [], False]
integersfoundso_far = 0
booleansfoundso_far = 0
for item in mixed_list:     if isinstance(item, int):         integersfoundso_far += 1     elif isinstance(item, bool):         booleansfoundso_far += 1

Output:

>>> integersfoundso_far
4
>>> booleansfoundso_far
0

2\.

>>> some_bool = True
>>> "wtf" * some_bool
'wtf'
>>> some_bool = False
>>> "wtf" * some_bool
''

3\.

def tell_truth():
    True = False
    if True == False:
        print("I have lost faith in truth!")

Output (< 3.x):

>>> tell_truth()
I have lost faith in truth!

💡 Explanation:

• bool is a subclass of int in Python

>>> issubclass(bool, int)
  True
  >>> issubclass(int, bool)
  False

• And thus, True and False are instances of int

>>> isinstance(True, int)
  True
  >>> isinstance(False, int)
  True

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

>>> int(True)
  1
  >>> int(False)
  0

• See this StackOverflow answer for the rationale behind it.

• Initially, Python used to have no bool type (people used 0 for false and non-zero value like 1 for true). True, False, and a bool type was added in 2.x versions, but, for backward compatibility, True and False couldn't be made constants. They just were built-in variables, and it was possible to reassign them

• Python 3 was backward-incompatible, the issue was finally fixed, and thus the last snippet won't work with Python 3.x!

▶ Class attributes and instance attributes

1\.

class A:
    x = 1
class B(A):     pass
class C(A):     pass

Output:

>>> A.x, B.x, C.x
(1, 1, 1)
>>> B.x = 2
>>> A.x, B.x, C.x
(1, 2, 1)
>>> A.x = 3
>>> A.x, B.x, C.x # C.x changed, but B.x didn't
(3, 2, 3)
>>> a = A()
>>> a.x, A.x
(3, 3)
>>> a.x += 1
>>> a.x, A.x
(4, 3)

2\.

class SomeClass:
    some_var = 15
    some_list = [5]
    another_list = [5]
    def init(self, x):
        self.some_var = x + 1
        self.somelist = self.somelist + [x]
        self.another_list += [x]

Output:

>>> some_obj = SomeClass(420)
>>> someobj.somelist
[5, 420]
>>> someobj.anotherlist
[5, 420]
>>> another_obj = SomeClass(111)
>>> anotherobj.somelist
[5, 111]
>>> anotherobj.anotherlist
[5, 420, 111]
>>> anotherobj.anotherlist is SomeClass.another_list
True
>>> anotherobj.anotherlist is someobj.anotherlist
True

💡 Explanation:

• Class variables and variables in class instances are internally handled as dictionaries of a class object. If a variable name is not found in the dictionary of the current class, the parent classes are searched for it.
• The += operator modifies the mutable object in-place without creating a new object. So changing the attribute of one instance affects the other instances and the class attribute as well.

▶ yielding None

some_iterable = ('a', 'b')
def some_func(val):     return "something"

Output (<= 3.7.x):

>>> [x for x in some_iterable]
['a', 'b']
>>> [(yield x) for x in some_iterable]
<generator object <listcomp> at 0x7f70b0a4ad58>
>>> list([(yield x) for x in some_iterable])
['a', 'b']
>>> list((yield x) for x in some_iterable)
['a', None, 'b', None]
>>> list(somefunc((yield x)) for x in someiterable)
['a', 'something', 'b', 'something']

💡 Explanation:

• This is a bug in CPython's handling of yield in generators and comprehensions.
• Source and explanation can be found here: https://stackoverflow.com/questions/32139885/yield-in-list-comprehensions-and-generator-expressions
• Related bug report: https://bugs.python.org/issue10544
• Python 3.8+ no longer allows yield inside list comprehension and will throw a SyntaxError.

▶ Yielding from... return! \*

1\.

def some_func(x):
    if x == 3:
        return ["wtf"]
    else:
        yield from range(x)

Output (> 3.3):

>>> list(some_func(3))
[]

Where did the "wtf" go? Is it due to some special effect of yield from? Let's validate that,

2\.

def some_func(x):
    if x == 3:
        return ["wtf"]
    else:
        for i in range(x):
          yield i

Output:

>>> list(some_func(3))
[]

The same result, this didn't work either.

💡 Explanation:

• From Python 3.3 onwards, it became possible to use return statement with values inside generators (See PEP380). The official docs say that,

"... return expr in a generator causes StopIteration(expr) to be raised upon exit from the generator."

• In the case of some_func(3), StopIteration is raised at the beginning because of return statement. The StopIteration exception is automatically caught inside the list(...) wrapper and the for loop. Therefore, the above two snippets result in an empty list.

• To get ["wtf"] from the generator some_func we need to catch the StopIteration exception,

try:
      next(some_func(3))
  except StopIteration as e:
      some_string = e.value

>>> some_string
  ["wtf"]

▶ Nan-reflexivity \*

1\.

a = float('inf')
b = float('nan')
c = float('-iNf')  # These strings are case-insensitive
d = float('nan')

Output:

>>> a
inf
>>> b
nan
>>> c
-inf
>>> float('someotherstring')
ValueError: could not convert string to float: someotherstring
>>> a == -c # inf==inf
True
>>> None == None # None == None
True
>>> b == d # but nan!=nan
False
>>> 50 / a
0.0
>>> a / a
nan
>>> 23 + b
nan

2\.

>>> x = float('nan')
>>> y = x / x
>>> y is y # identity holds
True
>>> y == y # equality fails of y
False
>>> [y] == [y] # but the equality succeeds for the list containing y
True

💡 Explanation:

• 'inf' and 'nan' are special strings (case-insensitive), which, when explicitly typecast-ed to float type, are used to represent mathematical "infinity" and "not a number" respectively.

• Since according to IEEE standards NaN != NaN, obeying this rule breaks the reflexivity assumption of a collection element in Python i.e. if x is a part of a collection like list, the implementations like comparison are based on the assumption that x == x. Because of this assumption, the identity is compared first (since it's faster) while comparing two elements, and the values are compared only when the identities mismatch. The following snippet will make things clearer,

>>> x = float('nan')
  >>> x == x, [x] == [x]
  (False, True)
  >>> y = float('nan')
  >>> y == y, [y] == [y]
  (False, True)
  >>> x == y, [x] == [y]
  (False, False)

Since the identities of x and y are different, the values are considered, which are also different; hence the comparison returns False this time.

• Interesting read: Reflexivity, and other pillars of civilization

▶ Mutating the immutable!

This might seem trivial if you know how references work in Python.

some_tuple = ("A", "tuple", "with", "values")
another_tuple = ([1, 2], [3, 4], [5, 6])

Output:

>>> some_tuple[2] = "change this"
TypeError: 'tuple' object does not support item assignment
>>> another_tuple[2].append(1000) #This throws no error
>>> another_tuple
([1, 2], [3, 4], [5, 6, 1000])
>>> another_tuple[2] += [99, 999]
TypeError: 'tuple' object does not support item assignment
>>> another_tuple
([1, 2], [3, 4], [5, 6, 1000, 99, 999])

But I thought tuples were immutable...

💡 Explanation:

• Quoting from https://docs.python.org/3/reference/datamodel.html

An object of an immutable sequence type cannot change once it is created. (If the object contains references to other objects, these other objects may be mutable and may be modified; however, the collection of objects directly referenced by an immutable object cannot change.)

• += operator changes the list in-place. The item assignment doesn't work, but when the exception occurs, the item has already been changed in place.
• There's also an explanation in official Python FAQ.

▶ The disappearing variable from outer scope

e = 7
try:
    raise Exception()
except Exception as e:
    pass

Output (Python 2.x):

>>> print(e)
prints nothing

Output (Python 3.x):

>>> print(e)
NameError: name 'e' is not defined

💡 Explanation:

• Source: https://docs.python.org/3/reference/compound_stmts.html#except

except E as N:
      foo

was translated into

except E as N:
      try:
          foo
      finally:
          del N

This means the exception must be assigned to a different name to be able to refer to it after the except clause. Exceptions are cleared because, with the traceback attached to them, they form a reference cycle with the stack frame, keeping all locals in that frame alive until the next garbage collection occurs.

• The clauses are not scoped in Python. Everything in the example is pr