Lisp mentality vs. Python mentality

Ciprian Dorin, Craciun ciprian.craciun at gmail.com
Sun Apr 26 01:58:19 EDT 2009


On Sun, Apr 26, 2009 at 8:11 AM, Steven D'Aprano
<steve at remove-this-cybersource.com.au> wrote:
> 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
> --

    I agree with your comment, the presented function compare does
more than this, in fact checks if the elements in the two functions
match a given binary predicate. (In Scheme this is named "andmap")

    About the compare (a, b, operator.lt) it does the same as a < b,
where a and b are lists of numbers.

    An usage for the compare function (as I've shown in a previous
post to this thread) could also have been checking a list of strings
if they match to a list of regular expressions (we rename the function
compare to the name "match" as it is much general):
        match (re.match, regexps, strings)

    About the defaults, I really, really, agree with your comment:
"Defaulting to equality testing is misleading"... Most of the times
equality means equality by value, but sometimes you need the equality
to be more relaxed (maybe ignore case, maybe ignore spaces, or maybe
for real numbers to ignore a difference smaller than a chosen delta
(those writing scientific applications know this too well))...

    Ciprian.



More information about the Python-list mailing list