An oddity in list comparison and element assignment

[Alex Martelli]

Slawomir Nowaczyk <slawomir.nowaczyk.847 at student.lu.se> wrote:

> On Thu, 01 Jun 2006 15:12:23 -0700
> michael.f.ellis at gmail.com wrote:
> 
> #> I believe that 'is' tests equality of reference, such that
> #> 
> #> >>> a = range(1,3)
> #> >>> b = range(1,3)
> #> >>> a is b
> #> False
> #> 
> #> The 'is' operator tells you whether a and b refer to the same object.
> #> What I've been discussing is whether == should test for "structural"
> #> equality so that a and b remain equivalent under parallel mutations
> #> (and also under single mutations to common references)
> 
> 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, since, e.g.:

ridiculous = c[0]

is not a "mutation" (so equality should still hold, right?), and then it
becomes weird to claim that

ridiculous.append('bah, humbug!')

is a "nonparallel mutation to" c and/or d.

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.

But of course, since Michaels still refuses to provide simple,
straightforward operational definitions of what it IS that he wants, all
of this remains vague and ill-defined.  See *WHY* it's so important to
provide precision rather than just the handwaving he's given so far?


Alex