Can a simple a==b 'hang' in and endless loop?

[Magnus Lycka]

Claudio Grondi wrote:
> You seem here to try to give a definition of the term 'value' for 
> Python. If I understand it right, the definition of the term can't be 
> generally given for many reasons. It depends at least on type and in 
> advanced usage it can be arbitrary defined or changed.
> That is why I mean, that it makes no sense to talk in Python about 
> value. I see not much sense in taking existing term in order to redefine 
> it for a new context - the result is always increase of confusion. Let 
> give it another name in order to know, that it must be defined for the 
> context it is used before it becomes meaningful.
> Any suggestions?

I think I understand what you mean. In e.g. C you have variables
with values. A variable is a location in memory where you can place
values of a certain type.

This "world-view" doesn't fit if you want to understand Python.

You always have three "thingies" in Python, instead of the two in
C. In C terminology you could say that you always use void pointers
in Python. (Of course, it's not as bad as it sounds, because of
all runtime checks and memory management etc, but you know that.)

So, in Python you have references, objects and content.

Sometimes the reference is just a slot in a container, e.g. if you
have "[0]" in your code, the list contains a reference to an
integer object with the content 0.

I think most people consider "value" and "content" to be synonyms,
but from the perspective of a variable name in the source code,
e.g. "a='hello'", there is always one level of indirection, since
there is always a pointer in between (and you can get that with
"id(a)").

The Python manuals refer to the names in Python programs (such as
"a" in "a=1") as variables, but some think that it's better to
call them "names" or "references", since they lack properties many
people associate with variables, for instance type.

If I return to C lingo again, datastructures in Python are always
made with malloc, and it's just these datastructures on the heap
that contain interesting values (or contents if you prefer that).

In C, pointers are particular types, and you can create pointer
chains that have an arbitrary length. Python don't have pointers.
You always get one level of idirection automatically, and the
referencing and derefencing is handled automatically. If you want
to chain data structures you can easily do that with containers
such as lists, or with classes you define yourself.

I don't think there are really any controversies concerning values
though. It's the content of the malloced datastructure. It's not
as ovbiously available in Python as in C, but it's still meaningful
to talk about it.

Then we get to the case of comparision operators in Python, such
as == and > etc. For simple types, they are used to compare the
values/contents of the compared objects in a fairly obvious way.
For containers such as list, Python declares that two lists are
equal if they have the same number of elements, and a pair-wise
comparision of all elements compare equal. E.g. ([a,b] == [c,d])
== (a==c and b==d). For classes you define, you get to decide
yourself how to implement comparisions.

This freedom in how to compare things shouldn't really influence
your view on values in Python. Values aren't defined through the
comparision operator.

One fundamental difference between C and Python is that C is a low
level language where you can directly access and manipulate the
computer memory. Python is a high level language where you can't
to that. You are limited to more abstract operations. I can see
how that makes thing feel more fuzzy. It's a bit like a car with
the hood welded shut. Also, Python is more flexible and customizable.
The comparision operators aren't hardwired to some basic machine
language instructions, their behaviour is defined in your code. It's
like fly-by-wire in modern airplanes. When the pilot pulls a lever,
it doesn't directly cause a rudder to move on a wing, it tells the
steering computer where the plane should go, and the computer decides
what rudders to move, and how much. That doesn't mean that it's
pointless to discuss rudders in modern airplanes.