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 -- http://mail.python.org/mailman/listinfo/python-list
