An oddity in list comparison and element assignment

[Tim Peters]

[michael.f.ellis at gmail.com]
> ...
> As I see it, reference copying is a very useful performance and memory
> optimization.  But I don't think it should undermine the validity of
> assert(a==b) as a predictor of invariance under identical operations.

So, as Alex said last time,

    Try concisely expressing your "should" -- constructively, as
    pseudocode that one could use to check for your "strengthened
    equality", not in abstract terms of constraints -- and if (as I
    strongly suspect) you cannot find a definition that is as simple,
    concise and natural as the two-liner above, this might help
    convince you that your desired definition would NOT be the most
    obvious, natural and fundamental, and therefore would not be
    appropriate to pick as part of the language's core.  Indeed,
    it's an interesting problem to code up, if one wants any generality
    (for example, identity of immutable items _whose items or
    attributes are in turn immutable_ probably should not matter even
    for your "strengthened" equality... but that's pretty hard to express!-).

So try that.  In reality, you can either learn to change your
expectations, or avoid virtually all object-oriented programming
languages.  Object identity is generally fundamental to the intended
semantics of such languages, not just an optimization.

Think about a simpler case:

    a = [1]
    b = a
    assert(a == b)
    a.remove(1)
    b.remove(1)

Oops.  The last line dies with an exception, despite that a==b at the
third statement and that ".remove(1)" is applied to both a and b.  If
you think a should not equal b at the third statement "because" of
this, you're going to lead a life of increasing but needless despair
;-)