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

[Claudio Grondi]

Steve Holden wrote:
> Claudio Grondi wrote:
> 
>> Steve Holden wrote:
> 
> [...]
> 
>> The problem here is, that I mean, that in Python it makes no sense to 
>> talk about a value of an object, because it leads to weird things when 
>> trying to give a definition what a value of an object is.
>>
> I don;t understand why you say that.
The same problem on my side. I don't understand, why you don't 
understand why I am saying that :-( .

> 
>> It seems, that in Python there is a lack of operator able to compare 
>> values as it is the case in C and Javascript, simply because in Python 
>> there are no really such things as values, so there is no need to 
>> compare them.
>>
> That is simply incorrect. The expression a == b is true under 
> well-defined circumstances usually referred to as "a and b having the 
> same value". There *are* such things as values. Presumably since you 
> know about "is", you also know about "id()". In C Python the id() of an 
> object is simply its memory address, though that isn't how id() is 
> defined. The fact remains that each object's id() must be unique at any 
> point in time (though id()s can be reused).
> 
>  >>> a = 10987
>  >>> b = 10987
>  >>> id(a)
> 4866328
>  >>> id(b)
> 4866340
>  >>> a == b
> True
>  >>>
> 
> See. Two different objects with the same value, so they compare equal.
> 
> Perhaps the difference you are having problems understanding arises 
> because Python also defines equality for complex objects.
> 
>  >>> lst1 = [a, b]
>  >>> lst2 = [b, a]
>  >>> lst1 == lst2
> True
>  >>>
> 
> Unlike C there is no need to compare each element of the lists: 
> list.__eq__() automatically iterates over the items of the list, and 
> returns True only if all pairwise comparisons return True.
> 
>> The higher level of abstraction/indirection in Python results in 
>> making the concepts of 'value', 'having a value' or 'comparing values' 
>> useless, where it helps in C to express the difference between address 
>> and content at that address and to distinguish between the information 
>> telling _what_ is stored in memory and the information about _where_ 
>> it is stored.
>>
> Well in Python each name in a namespace, and each attribute of an 
> object, and each item in a sequence or a mapping, is a reference to a 
> value. Where the value is stored is completely irrelevant, and addresses 
> are only available as an implementation detail in CPython. You can test 
> if two references are to the same object using "is", which you already 
> know. In other words
> 
>       a is b       is exactly       id(a) == id(b)
> 
> Obviously "a is b" implies "a == b", whereas the converse is not true.
Obviously not, see code below:
<PythonCode>
print """
class classWithAlwaysFalseComparison:
   def __eq__(self, other):
     return False
a = classWithAlwaysFalseComparison()
b = a
"""
class classWithAlwaysFalseComparison:
   def __eq__(self, other):
     return False
a = classWithAlwaysFalseComparison()
b = a
print 'a is b is %s, but a == b is %s'%(a is b, a==b)
</PythonCode>
<PythonCode-Output>
class classWithAlwaysFalseComparison:
   def __eq__(self, other):
     return False
a = classWithAlwaysFalseComparison()
b = a

a is b is True, but a == b is False
</PythonCode-Output>

That is, where the intuitive reasoning fails in Python, right?
Do you understand _now_, why I was saying what you don't understand why 
I was saying it?

> 
>> It appears to me, that the whole subject of what an identifier in 
>> Python represents and if there is such thingy as 'value' in Python, is 
>> not perfectly well understood even by Python experts programming also 
>> in many other languages and therefore the vital differences in 
>> concepts behind Python and e.g. C/C++ is only poorly documented . What 
>> else would be the reason for the over-long discussion in the "Is 
>> 'everything' a refrence or isn't it?" thread in this newsgroup?
>>
> It may so appear to you, but that doesn't make it the case. The reason 
> for the overly-long discussion is that people insist on picking the 
> smallest details to bits and arguing over small semantic differences 
> that are irrelevant to getting programs working.
> 
> I have an idea that the people who wrote and maintain the interpreter 
> find these concepts quite comprehensible, and I don't have any problem 
> myself. I suspect you are externalising your confusion.

I am not confused myself today and I was not confused at the time I have 
posted my own reply "Re: Is 'everything' a refrence or isn't it?" to the 
appropriate thread, but in between I become aware of the fact, that my 
understanding of Python on 2006-01-04 when I wrote my reply and today 
changed to a much deeper and gave me more insight into the 
behind-the-scenes and the major concepts behind Python.
Interesting in this context is the fact, that nobody felt that time the 
need to correct my notion that Python identifiers have no values in 
sense of terms used in C as I wrote:
"""
if you write
   for i in lst:
then the identifier  i  'points' to values in  lst, but else as in C 
where you can use a pointer to change the value it points to by 
assigning to *i or where you can use a reference to change a value it 
references, in Python you don't change a value of  i  because  i  is an 
identifier and therefore has no value in sense of C - it is only a name 
used to reach a value.
"""
What I would like to change in this text above today is the phrase:
"i  is an identifier and therefore has no value in sense of C - it is 
only a name used to reach a value."
to
"i  is an identifier and therefore has no value in sense of C - it is 
only a name used to reach a Python object."
in order to get out of the hassle the concept of 'value' causes in Python.

> 
>>  From what I know about Python up to now, the problem with the concept 
>> of 'value' in Python is, that it depends ... and it depends on so many 
>> things, that it is hard to give any general valid statement about it 
>> without writing an entire chapter full of details and special cases.
>>
> Well, you really are making something extraordinarily easy much more 
> difficult than it needs to be. I don't even really understand why you 
> need a written definition of "what a value is", come to that.
> 
> Why don't you write some C that you thing it would be difficult to 
> rewrite it Python?
> 
> There really is no need to be so obsessive about where things are 
> stored. It simply doesn't matter in a language with no pointer types.
It is probably true, that it doesn't much matter when writing Python 
code when one do not understand how Python works internally. The rare 
practical cases of getting into trouble because of lack of such 
understanding can be easily overcome by performing some testing or 
asking in the comp.lang.python .
As I see, the question is here, if it is worth the effort to try to 
change the way people speak about Python and understand what Python code 
does in order to avoid this rare cases of getting into trouble?

By the way, after I have explained the why behind my question, the focus 
of this thread has moved, so, that my genuine question has been 
forgotten in the mess of the responses. It seems, that it is not 
necessary an advantage to tell about the background of the question 
asked. I should probably consider it asking next question in order to 
avoid an unnecessary not subject related flood of responses.

Claudio
> 
> regards
>  Steve