An oddity in list comparison and element assignment
steve at holdenweb.com
Mon Jun 5 13:44:20 CEST 2006
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
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.
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
More information about the Python-list