An oddity in list comparison and element assignment

[Jim Segrave]

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)