> > You definitely have to stop thinking of variables as containers. They > > are pointers or references to values. Another way to think of this is > > that variables are names for things. > Kent that's a perfectly understandable and easy to grasp analogy. But it > stays just an analogy ;-)
Nope. In Python it is what happens. Python implrements most things using dictionaries under the covers. When you create a new variable name by doing something like n = 42 Python does something like: variables['n'] = 42 where variables is a dictionary. You can even print the dictionaries if you know the right magic words ;-) when you access a variable by typing print n Python translates that to print variables['n'] > Thing is. We people consist of more than a 1st name to identify ourself. Yes we have identity. And so do Python variables (the actual objects that the names point at, not the names) and we can print the identity out by using the id() function: x = 42 y = x z = y print id(x), id(y), id(z) will all print out the same id since Python caches low value integers and all three names point at the same stored value. > coding is not IRL and isn't a reflection of it either. But creating a reflection of real life is the goal of programming designers for decades. The whole OOP thing came out of attempte to model the real world using the simulation language Simula. > Coding is alot easier bacause it does not require that 2 variables > need to be linked. True, but not being able to link them causes its own problems. Some languages, like C/C++ allow both styles: int n = 42 // n is a memory location which holds 42 int &x = n // n is a memory location that points at whatever n contains. printf ("%d\t%d",n,x) / prints 42 twice n = 27 printf ("%d\t%d",n,x) / prints 27 twice Python takes the approach that references are generally easier to work with than static values, but they do bring their own perils... > coding with the knowledge A is A and A is never B. This was true in the very oldest languages like COBOL and Fortran and BASIC but even Lisp, which is of the same c1960 vintage, used references. And almoist all languages since the late 60s have had some form of reference mechanism. Most languages since the late 1980's have tended to make variable naming by reference the default. > When would I have need of this? When the real world works thatv way, which is often. When you want to minimise machine resource by avoiding multiple copies of the same data When you want to minimise the number of names in your code - it is essential for dynamic typing! When you want to use OOP, static objects are virtually never polymorphic and hence are very limited in usefulness. > Or why do I want it? Where is the benefit? The benefits are real and the reasons above indicate some of them. But there is a dark side as you have discovered. There are times when a static definition is more logical. > for x in range(3): > > I know it is shorthand for something like (not exactly but it > serves its purpose as an example): In fact that may be how you think of it as an analogy to how you are accustomed to programming but in fact it is nothing like that. Pythons for loop is much more sophisticated and uses iterators which in turn use polymorphism within Pythons object model. That relies on the names being references. > x = 0 > while x<=3 do: > x = x +1 > > And I understand why it is done this way: So how does your analogy work with this code: for item in [1,'aString', lambda x: x*x, True]: print item You now need to change your code to incorporate a call to len() and incorporate the concept of an index. But what if the object being iterated has no len capability, it may even be infinite in length (a generator function say)? Like this: def f(x): n = 2*x while True: n *= 2 yield n for y in f(2): print y This is getting into subtleties I know, but it illustrates just how much more powerful Pythons apparently simple structures are, and they rely on the use of named bindings rather than static variable containers. > Oh and tell me to shut up and just accept it if you want to ;-) No, its always better to ask. Sometimes we may not understand the answer, or may not agree with the answer or whatever. But its always better to ask. And sometimes the answer in Python is simply that Guido van Rossum prefers it that way! Alan G. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor