In the Wrapping Up section, there are some very interesting points that weren't covered in the article.

  - Why is "list += seq" not the same as "list = list + seq"?
  - Why is "is" different than "==" and how come "2 + 2 is 4", but "1000 + 1 is not 1001"?
  - What's the deal with mutable default arguments to functions?
  - Why is it easy to make a list class attribute, but hard to make an int class attribute?

I'd love to read an article on these topics. Anyone have links?

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

To get more specific, this object aliasing is an implementation detail. You can't expect different Python implementations to do it the same.

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

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

You're correct.

Further, there are some odd quirks because of the way Python caches small Integers for efficiency.

  > 2 + 2 is 4
  True
  > 1000 + 1 is 1001
  False

For more details:

http://stackoverflow.com/questions/306313/python-is-operator...

After a little trial and error, it appears that Python caches the values in range(-5,257).

  > -6 + 0 is -6
  False
  > -5 + 0 is -5
  True
  > 256 + 0 is 256
  True
  > 257 + 0 is 257
  False

(CPython)

    > 2 + 4 is 4
    True

I sure hope not.

lol, thanks, i fixed it

(I think you meant 2 + 2 is 4)

Ned always has fantastic articles, and the way this is lays out the mutable values name relationship, is it just lazy programming that has multiple names pointing to the same mutable value(s) or are their specific cases when that would make since to have list(a) list(b) point to the same value(s)?

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

JavaScript works identically.

Personally, THIS is what an "intro to language X" article should look like. It walks you through how the language thinks, which is one of the things you need to learn in order to understand how to best use it and why things are the way they are.

The vizualizations on pythontutor.com are really helpful in explaining those concepts.