Re: An oddity in list comparison and element assignment
- From: aleax@xxxxxxx (Alex Martelli)
- Date: Thu, 1 Jun 2006 19:16:16 -0700
Slawomir Nowaczyk <slawomir.nowaczyk.847@xxxxxxxxxxxxx> wrote:
On Thu, 01 Jun 2006 15:12:23 -0700
michael.f.ellis@xxxxxxxxx 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
.
- Follow-Ups:
- Re: An oddity in list comparison and element assignment
- From: Slawomir Nowaczyk
- Re: An oddity in list comparison and element assignment
- References:
- An oddity in list comparison and element assignment
- From: michael . f . ellis
- Re: An oddity in list comparison and element assignment
- From: Alex Martelli
- Re: An oddity in list comparison and element assignment
- From: michael . f . ellis
- Re: An oddity in list comparison and element assignment
- From: Slawomir Nowaczyk
- An oddity in list comparison and element assignment
- Prev by Date: Re: An oddity in list comparison and element assignment
- Next by Date: Re: Best Python Editor
- Previous by thread: Re: An oddity in list comparison and element assignment
- Next by thread: Re: An oddity in list comparison and element assignment
- Index(es):
Relevant Pages
|