On Sat, 25 Apr 2009 10:30:56 +0200, Martin v. Löwis wrote: >>>> Ok... Then what's pythonic? Please give a pythonic >>>> implementation... >>> Use the builtin a==b, similar to (equal a b) >> >> But how about extensibility? > > == is extensible. To compare two things for equality, use ==. > > This is what Carl Banks referred in his original posting. You just > *don't* implement a function that compares two lists, not even as an > exercise for estetic, optimal, and useful implementations - because > you'll know that it won't be useful, anyway, if you can already use the > builtin == in the first place. > > I see that you allow for a different comparison function. I do wonder > what the use case for this is - in what application do you have to > compare two lists for equality, and the item's __eq__ is inappropriate?
The above doesn't really compare for equality, it's a generic element-by- element comparison function, and so it is inappropriate to contrast it to __eq__ alone. Defaulting to equality testing is misleading, and if I were writing such a function I'd remove the default. compare(a, b, operator.eq) gives the same result as the simpler a == b, but compare(a, b, operator.lt) does something very different to a < b. I can't think of an application for element-by-element comparisons off the top of my head, but if the numpy people use it, there must be a need :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
