An oddity in list comparison and element assignment

[Steve Holden]

michael.f.ellis at gmail.com 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