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

[Claudio Grondi]

Steven D'Aprano wrote:
> On Wed, 18 Jan 2006 15:29:24 +0100, Claudio Grondi 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.
> 
> 
> Python object: 1
> The value of that Python object: the int 1
> 
> Python object 4.7
> The value of that Python object: the float 4.7
> 
> Python object "abc"
> The value of that Python object: a string consisting of characters a, b
> and c.
> 
> Python object [1, 4.7, "abc"]
> The value of that Python object: a list containing objects 1, 4.7 and "abc".
> 
> 
> Where's the problem?

My problem is, that I don't know if it is possible and if yes how to 
overwrite the __eq__() methods of the built-in types.
With not built-in types I can do:
class classWithWeirdEqualityBehaviour:
   def __init__(self, value)
     self.value = value
   def __eq__(self, other):
     return False
a = classWithWeirdEqualityBehaviour(1)
b = classWithWeirdEqualityBehaviour(1)
a==b # gives False

> 
> 
> 
>>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.
> 
> 
>>>>1 == 1
> 
> True
> 
>>>>4.7 == 1
> 
> False
> 
> Works for me.
> 
> 
> 
>>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.
> 
> 
> In Python, you never care _where_ anything is stored. The id() function
> returns the unique ID of an object, which as an implementation detail may
> be the actual memory address, but that's just an implementation detail. In
> any case, given a memory address, you can't do anything with that
> knowledge.

The question here is, if this a handicap or a welcome feature?

 From the one side I am glad that Python cares about memory allocation 
for me, but on the other side I have trouble to accept, that I have no 
direct access to the memory area where data are stored in order to 
manipulate them. Having this possibility would enormously speed up some 
conversions, because it were possible to get them down to a redefinition 
of the data structure without being forced to loop over the actual 
content or use a special extension library written in C for doing that.

Claudio