On 07/05/2010 19:57, 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. > Sure, but in CPython at least you *could* detect *identical* functions (but not functions that do the same thing in a different way). All the information is exposed - it would mean comparing bytecode though (plus signature etc) and is not likely to be portable to other implementations. Partials that wrap the *same* function (based on identity) comparing equal seems useful enough to me. Michael -- http://www.ironpythoninaction.com/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4