[Tutor] list method help

[Alan Gauld]

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