# An oddity in list comparison and element assignment

michael.f.ellis at gmail.com michael.f.ellis at gmail.com
Thu Jun 1 20:32:15 CEST 2006

```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.

Cheers,
Mike

Jim Segrave wrote:
> In article <1149177617.985251.74560 at c74g2000cwc.googlegroups.com>,
>  <michael.f.ellis at gmail.com> wrote:
> >Hi Alex,
> >With all due respect to your well-deserved standing in the Python
> >community, I'm not convinced that equality shouldn't imply invariance
> >under identical operations.
> >
> >Perhaps the most fundamental notion is mathematics is that the left and
> >right sides of an equation remain identical after any operation applied
> >to both sides.  Our experience of the physical world is similar.  If I
> >make identical modifications to the engines of two identical
> >automobiles, I expect the difference in performance to be identical.
> >If my expectation is met, I would assert that either the two vehicles
> >were not identical to begin with or that my modifications were not
> >performed identically.
> >
> >As to containers,  would you say that envelope containing five \$100
> >bills is the same as an envelope containing a single \$100 bill and 4
> >xerox copies of it? If so, I'd like to engage in some envelope
> >exchanges with you :-)
> >
> >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.
>
> I think you end up with a totally unwieldy definition of '==' for
> containers, since you have to check for _identical_ aliasing to
> whatever depth it might occur, and, if you insist on equality
> modeling the physical world, two lists can only be equal if:
>
> for each corresponding element in the two lists, either the element is
> a reference to the same underlying object or the corresponding
> elements are references to objects which do not have and never will
> have other references bound to them.
>
> For example:
>
> ra = ['a', 'a']
> rb = ['b', 'b']
>
> l1 = [ra, rb]
> l2 = [ra, rb]
>
> This will be equal by your definition and will preserve equality over
> identical operations on l1 and l2
>
> l3 = [ ['a', 'b'], ['a', 'b']]
>
> This list will be identical, under your definition, so long as we
> don't have anyone doing anything to the references ra or rb. Your
> equality test has to claim that l1 and l3 are not equal, since ra
> could be changed and that's not an operation on l1 or l3
>
> This also leaves out the complexity of analysiing nested structures -
> if you have a tuple, containing tuples which contain lists, then are
> those top level tuples 'equal' if there are aliases in the lists? How
> many levels deep should an equality test go?
>
> Does the more common test, to see if the elements of a sequence are
> identical at the time of comparision need a new operator or hand
> coding, since most of the time programmers aren't interested in future
> equality or not of the structures.
>
> --
> Jim Segrave           (jes at jes-2.demon.nl)

```