An oddity in list comparison and element assignment

[Slawomir Nowaczyk]

On Thu, 01 Jun 2006 19:16:16 -0700
aleax at mac.com (Alex Martelli) wrote:

#> > What does "parallel mutations" mean? In particular, what should be the
#> > results of each of the following three comparisons:
#> > 
#> > x, y, z = [1],[1],[1]
#> > a, b = [x,y], [y,z]
#> > c, d = [[1],[1]], [[1],[1]]
#> > a == b
#> > c == d
#> > a[0].remove(1)
#> > b[0].remove(1)
#> > a == b
#> > 
#> > So, do I understand correctly that you would like first comparison
#> > (a==b) to return "False" and second comparison (c==d) to return
#> > "True"?
#> 
#> I sure hope not,

So do I, but that's how I understood Michaels' words...

#> In fact, I'm starting to wonder if by Michaels' requirement ANY
#> non-*IDENTICAL* containers (with non-identical mutable items) could
#> EVER be deemed "equal". If he's arguing that "==" should mean
#> exactly the same as "is", that's even crazier than I had gauged so
#> far.

I think he explicitly said that "is" doesn't fulfill his requirements
either... but then, I am not sure as I do not understand what his
requirements actually are (they seem to make some sense for immutable
objects, but how should they generalise to mutable stuff I have no
idea).

PS. Thanks for explanation about Bank of America: I had no clue how it
works in realty, it just had a good name ;)

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( Slawomir.Nowaczyk at cs.lth.se )

Java is clearly an example of a MOP (money-oriented programming)
  -- Alexander Stepanov