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

[Claudio Grondi]

Fuzzyman wrote:
> Claudio Grondi wrote:
> [snip..]
> 
>>Yes, I know about 'is',
>>
>>but I mean, that it is not possible to use 'is' as replacement for '=='
>>operator to achieve in Python same behaviour as it is the case in C and
>>Javascript when comparing values with '=='.
>>'is' does the C, Javascript job when comparing lists, but I mean it
>>fails to give fully predictable results when applied to elements of
>>lists in case there exist duplicate objects with same 'value' i.e. e.g.
>>there are two different objects storing the integer value 1, what I mean
> 
> 
> Hmmm... :
> 
>  >>> a = 1
>  >>> b = 1
>  >>> a is b
> True
> 
> Doesn't work with arbitrary longs of course...
I didn't discovered yet myself that even in this simple case

 >>> a = 1L
 >>> b = 1L
 >>> a is b
False

Python fails to reuse the long integer object. It would be interesting 
to know why, because it seems to be strange, that in case of integers it 
does (but not always and I don't know actually when it happens and what 
it depends upon). Reusing long integers would make much more sense than 
reusing plain integers when considering memory spent on storage.
Hmmm...

> 
>>can happen when there is enough other code between the Python code lines
>>assigning the integer value 1 to a list element or any other identifier.
>>Or is there in Python a 100% reliable mechanism assuring, that there is
>>one and _only one_ object carrying a given 'value' (at least for the
>>built in types as integer, long integer, string, float) and if this
>>value is to be assigned to a list element or any other literal the
>>already existing object (if any) will be found and used/referenced?
>>
> 
> 
> So the Java/C '==' operator sometimes works like '==' in Python and
> sometimes works like 'is' ? (It switches between equality and identity
> depending on the types being compared IIUC).
Yes, this is how I understand it now, with the difference, that Python 
adds one additional level of indirection here as there is no plain value 
in Python referenced by an identifier, but an object which behaviour 
depends ...
 From my point of view Javascript/C effect of '==' is consistent where 
in Python it's not, but from other long discussions I know, that it 
seems to be a matter of taste.
I don't know much enough about Java to speak about it. I know much more 
about JScript/Javascript being more like Python is. It is _important to 
distinguish_ between Java as a programming language with its VM and 
Javascript as an engine working inside dynamic HTML pages (unless one is 
on Windows and has the JScript engine available for both purposes: 
inside HTML and stand-alone scripting engine).
You write "So the Java/C '==' operator" - I suppose that Java and C 
probably differ here, but I'm not sure. Maybe someone else can tell 
something about it using a simple example of Java code equivalent to 
Python code:
a=[1]
b=[1]
print a==b
print a[0]==b[0]

> 
> My understanding is that you can't use '==' in Java to compare strings,
> because it is an identity test not an equality test. You have to use a
> string method to compare strings. This bites quite a few people...
In Javascript you can do that. Try in an HTML page to write:
<script language=javascript>
s1 = 'abc';
s2 = 'abc';
alert(s1==s2);
s2 = 'bcd';
alert(s1==s2);
</script>
and see the True/False in the raised message boxes.

> 
> Anyway, AFAICT your problem only matters in the abstract (where you are
> theoretically comparing objects you haven't specified the type of and
> *might* want to use '==' and *might* want to use 'is').
> 
> For practical purposes '==' will do what you want, unless you
> deliberately create buggy code to cause a problem when you use it...
> 
> Unless you can post an example of *non-buggy* code that doesn't behave
> how you expect ?
That's not possible, because if the code doesn't behave how I expect, it 
will be considered buggy by definition of what buggy code is. So the 
problem always is that the programmer haven't understood something right 
writing it (unless there is a bug in the Python interpreter itself one 
is running into, but this is not the subject here).

I mean, that the more specific the interpretation of code can become 
depending on context, the more I have also to know reading a line at the 
end of a script about what was written before, making the code more 
difficult to read and understand. It is sure a matter of taste if one 
likes it that or the other way, but it is important for me to understand 
which way it actually is when using or choosing a programming language 
for a given kind of task.

The reason why I switched to Python from Microsoft JScript (which is the 
dynamic HTML javascript empowered with ActiveX and all Windows specific 
things able to write files and do anything Python can do) is the 
availability of C code of the scripting engine and the ability to work 
cross-platform due to support by using it Python community (member of 
which you can find spread over almost any of the various existing 
platforms and systems).

Claudio