Lisp mentality vs. Python mentality

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Sun Apr 26 01:11:02 EDT 2009


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



More information about the Python-list mailing list