Facts and myths about Python names and values

I think two different objects that evaluate to the same thing pass the `==` test, but is checks for identity?

  >>> a = list()
  >>> b = list()
  >>> a is b
  False
  >>> a==b
  True
  >>>

    > list += seq

uses the __iadd__ method, which almost certainly uses the exact same mechanism as the list.extend() method. When this method isn't defined (c.f. the Counter class from the collections module), a += b works like a = a + b.

    > from collections import Counter
    > c = Counter()
    > c_old = c
    > d = Counter()
    > c += d
    > '__iadd__' in dir(c)
       False
    > c_old is c
       False
    > a = []
    > a_old = a
    > b = []
    > a += b
    > '__iadd__' in dir(a)
       True
    > a_old is a
       True

I'm not sure about list += one. Would have to dissemble to determine "why". The '+' operator is not defined for all possible sequence types (could never be given user definable types). So, in many instances (e.g. adding tuple to list) l=l+s will TypeError. += for list must be defined to "cast" the sequence into list. Something like "l = l + list(s)". List constructor must iterate over the sequence to create list. By definition a sequence must be iterable. So l += s will work for all (s).

"is" operator determines if two things are the same thing, contrast with two things evaluate to the same value, "==". It's probably implementation dependent but "same thing" is same memory location. CPython "interns" (keeps a table/cache) of small integers rather than allocating them anew (for speed and space efficiency). All names referring to the value of integer '4' are referring to the same value. Possible cause integers are immutable. Were as names referring to larger ints may or may not be referring to the same value, even when those values are equal.

Default mutable arguments have been talked about a lot. Google it. You should already grok it after learning what OA taught you about names / reference and knowning that function/method definitions are executed once (at import/"parse"). So, the list that the name "mutable" refers to is created once, when defined (which is usually once But inner functions and programatically generated functions could be more). All calls of that function will be using the same name "mutable" all of which refer to the same list.

  def func(mutable=[]): 
     mutable.append(len(mutable))
     print mutable

I'm not sure what is meant by class attribute and esp, given that he just wrote whole article on how names (attributes are names) don't have types, values do, what is meant by list or int attribute.

> 1000 + 1 is not 100

'is' actually checks memory locations and not equity.

Because of the way Python caches small integers, anything from 0 through X will map to the same memory location. But a large integer (say 1001) will map to a new memory location each time its created.

Because of the stuff mentioned later, that function application, for loops, and all kinds of other things are fully "assigment" as well, Python is just flinging around all kinds of names all over the place (it is essentially what a Python program is in many ways) and it is inevitable that there is no one-to-one mapping, and that duplications will happen all the time. After all,

    x = 1
    y = [x, 2]
    for z in y:

"naturally" creates a duplicate binding on the value of x, without anything as crass as "x = y = []". As is always the case of a three-line example in a little post, when found in the wild this can be a much more hidden thing in the middle of a 50-line function. (Which of course nobody ever writes because all 50-line functions are too long, and therefore, no 50-line functions actually exist. But if they did, this sort of thing would happen in them all the time.)