On Sat, 8 May 2010 03:57:06 am Steve Holden wrote:
Steven D'Aprano wrote:
On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
Sorry to grouse, but isn't this maybe being a bit too clever? Using your example, p1 = partial(operator.add) is creating a callable, p1, i.e. a sort of function. Yes I know technically it's not a function, but it behaves very much like one.
Now, if I write
def f1(x,y): return x+y def f2(x,y): return x+y
I don't expect f1==f2 to be True, even though f1 and f2 behave in exactly the same way, and indeed it is not.
I do expect f1==f2, and I'm (mildly) disappointed that they're not.
How about
def f1(x, y): return x+y def f2(x, y): return y+x
As you know, there are limits to everything. It seems to me that while pure mathematics can (sometime) easily determine functional equivalence, once you get to code it's a lot harder because there are semantic constraints that don't apply in pure mathematics.
This being Python, we can't assume x+y is always equal to y+x, so in your example I wouldn't expect them to be equal. And thus I avoid your trap :) What you say is correct in general. I understand the arguments against making function equality more sophisticated than just identity testing: there aren't many use-cases for it, and it is potentially a lot of work depending on how clever you try to be. But if it came for free, it would be a sweet trick to impress your friends and scare your enemies. [...]
I think it is reasonable to expect that partial(operator.add, 2) compares equal to partial(operator.add, 2). I don't think he's suggesting it should compare equal to partial(lambda x,y: x+y, 2).
Which absence, presumably, also mildly disappoints you?
Only in the sense that in a perfect world where language features had benefits but no costs, I would expect nothing less. -- Steven D'Aprano