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

[Steve Holden]

Claudio Grondi wrote:

 >
 > ------------------------------------------------------------------------
 >
 > Subject:
 > Re: Can a simple a==b 'hang' in and endless loop?
 > From:
 > Claudio Grondi <claudio.grondi at freenet.de>
 > Date:
 > Wed, 18 Jan 2006 19:59:12 +0100
 >
 > Newsgroups:
 > comp.lang.python
 >
 >
 > 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?
 >
Yes. It's a bit like complaining that you bought a gun and you now 
realised it can kill people. Python is a language for "consenting 
adults": you can use its introspection capabilities to creat 
non-intuituve results.

 >>
 >>> 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.
 >
As we often abbreviate it: names in Python are always references.

 >>
 >>>  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?
 >
Precision is alwayds welcome, but sometimes practical discussions 
require a certain imprecision simply to allow discussions to move 
forward. Goodwill on both sides is always helpful.

 > 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.
 >
c.l.py can be a bit like that!

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                  www.python.org/pycon/