Rereading my essay, I think I begin to understand where the "mutable - immutable" comments come from (You see - it was even useful to ME ;-) )
Before I go on, just one petty remark (re: the quotes in the essay) - mutability is a property of objects, not of names (it's actually a categorization of types, and objects are typed), so you have to say "mutable values", not "mutable variables". To explain where the 'common concept' variables might cause unavoidable complication I had said: >Note that usually they would not say all of that in the first lesson (as >this is >obviously too complex). Instead they would just develop this mental picture >gradually. They'd start with "named areas of memory", then at some point >they >have to explain stuff like "a=[];b=a;b.append(1);print a,b" and things start >getting complex real fast. > > Now, I 'd used a *list* in my example[1], which is a mutable object. Why's that? Because in almost any program (unless your'e writing pretty delicate things relying on reflection) you expect to see the exact same results whether you use the same object or a copy of it - unless you actually go and *change* the object. And you can only[2] change a *mutable* object. If we stick to "examples should only use code that does useful things" (one of the best tips I recently learned from you :-) ), you'll only be able to see any difference between the two variable models if your objects are mutable. List is the first multable type in this course, so now your comments make more sense to me. ------- [1] Obviously, using "is" or "id", I could have shown the same thing with immutables: "a=3;b=a;print a is b", but you might want do the whole course without mentioning 'id' and 'is'. [2] More exactly, your'e not *supposed* to change immutable objects. In fact, only last week I've done just that - changed a python string - just to verify I got my ctypes.LP_c_char_p objects pointing where they should. Obviously, this is *NOT* the sort of thing one would want to show in a course...
