1.

2.

3.

Double-click (or enter) to edit

4.

Output (< Python3.7 )

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

Double-click (or enter) to edit

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

So, 1 < 1 evaluates to False

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

1.

2.

3. Output

Output (Python 3.7.x specifically)

Double-click (or enter) to edit

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,

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

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.

Output

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

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

1.

Output:

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

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

• 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 here), 5, 5.0, and 5 + 0j have the same hash value.

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, and degrades the constant-time performance that hashing usually provides.)

Output:

Double-click (or enter) to edit

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

Output:

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

Output

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

  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,

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

Output:

Double-click (or enter) to edit

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

Output:

Double-click (or enter) to edit

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

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

Double-click (or enter) to edit

1.

Output:

2.

Output:

3.

Output:

Double-click (or enter) to edit

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

• Okay, going by the logic discussed so far, shouldn't be the value of list(g) in the third snippet be [11, 21, 31, 12, 22, 32, 13, 23, 33]? (because array_3 and array_4 are going to behave just like array_1). The reason why (only) array_4 values got updated is explained in PEP-289

  Only the outermost for-expression is evaluated immediately, the other expressions are deferred until the generator is run.

Double-click (or enter) to edit

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

Output:

We didn't assign three "X"s, 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 issue).

Double-click (or enter) to edit

Output (Python version):

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.

Double-click (or enter) to edit

• 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. The function looks up x in the surrounding context, rather than using the value of x at the time the function is created. So all of the functions use the latest value assigned to the variable for computation. We can see that it's using the x from the surrounding context (i.e. not a local variable) with:

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

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

Output:

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

Double-click (or enter) to edit

1.

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

2.

3.

Double-click (or enter) to edit

• 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,
  • class A is an instance of class B, and class B is an instance of class A.
  • class A is an instance of itself.
• 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.

Output:

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)