What happens if I say x = x? (On a low, compiler level)

Question

In Python (more specifically Python 3.x), what happens if I say x = x, where x is either a reference to a mutable (like list) or a reference to an immutable (like int) on the low-level? Does the compiler simply ignore such nonsense?

More specifically, what does the compiler do if we have the following case:

class A:
    def __init__(self):
        self.a = self.init_a()

    def init_a(self):
        self.a = some_value
        """
        do stuff with self.a here
        """
        return self.a

For those who haven't noticed, self.a effectively gets assigned to itself through the function, init_a(self).

I know this case with class A above seems silly, but I am trying to keep my code clean and readable by clearly initializing all my member variables inside the __init__(self) function (in a different class that I am implementing for real). I just want to know for interest's sake whether the compiler optimizes that step away, or whether it does some operations in any case, even though the statement does not result in anything (I'm guessing it gets optimized away, but I want to be sure - you never know).

Answer 1

from dis import dis

def foo():
    x = 1
    x = x

dis(foo)

Result:

  4           0 LOAD_CONST               1 (1)
              3 STORE_FAST               0 (x)

  5           6 LOAD_FAST                0 (x)
              9 STORE_FAST               0 (x)
             12 LOAD_CONST               0 (None)
             15 RETURN_VALUE 

This shows that even in the most trivial case, x = x is NOT optimised away (in CPython, which is what dis is for).

Answer 2

I just want to know for interest's sake whether the compiler optimizes that step away, or whether it does some operations in any case, even though the statement does not result in anything.

Unless the Python Language Reference says something about it¹, then any optimization or lack of it is implementation specific². You can investigate what a particular Python implementation does with this, but you cannot generalize to all Python implementations.

---

^{1 - My cursory search of this copy of the spec does not real any relevant discussion of optimization. Ergo, my reading would be that valid optimizations are permitted but not required. (A valid optimization would be one that does not alter any observable behavior of a valid Python program that is clearly required by the spec.)}

^{2 - Indeed the spec says this: "Each of these implementations [listed above in the spec] varies in some way from the language as documented in this manual, or introduces specific information beyond what’s covered in the standard Python documentation. Please refer to the implementation- specific documentation to determine what else you need to know about the specific implementation you’re using."}

Answer 3

This may seem very strange, but it is not actually possible to implement the optimization you suggested, as python is far too dynamic.

Consider the following code:

[Definition of your A class]
@property
def sneaky(self):
    return self._a
@sneaky.setter
def sneaky(self, value):
    self._a = value * 2
A.a = sneaky
a = A()

The self.a = in the __init__ method suddenly starts having an effect! It doubles the value of a. Python is very dynamic indeed.