[EMAIL PROTECTED] wrote: > Yes. You stated it quite precisely. I believe l1==l2 should always > return True and l1==l3 should always be False. (unless l3 is reassigned > as l3=l1). Your idea of a separate operator for 'all elements have > numerically equal values at the moment of comparision' is a good one. > For want of a better name, it could be called DeepCopyEquality(a,b) and > would be equivalent to a byte-by-byte comparison of two distinct > regions in memory created by a deep copies of a and b. > I suspect the word you are grasping for is "isomorphic", since your complaint appears to be that two non-isomorphic lists can compare as equal.
He then later said: > Considering the number of new programmers who get bit by automatic > coercion, I wish Dennis Ritchie had made some different choices when he > designed C. But then I doubt he ever dreamed it would become so wildly > successful. > So he designed it badly because he didn't anticipate its ubiquity? Give me a break. Every language designer regrets some of their decisions: it's almost a given for design of any kind, since one makes compromises without realising that they are compromises until usage reveals them. > Being a curmudgeon purist I'd actually prefer it if Python raised a > TypeError on float vs integer comparisons. > That's taking purity just a little too far for my taste. Looking at how this thread developed (if such an unedifying process can be described as "development") I hope you'll phrase future posts a little more carefully. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Love me, love my blog http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list