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