"Phillip J. Eby"
At 09:36 AM 10/25/04 -0700, Guido van Rossum wrote:
I can't think of an application where the current behaviour would be of great benefit. It's always possible to create a tuple of the fields you want in the comparison. Unless it caused a drop in performance, I'd be in favour of only having identity comparison for code objects.
Well, then perhaps code object comparison (and function object comparison) ought to work the same as 'is', not try to do something clever?
+1
Isn't that what function objects do now? (for some value of "now")
Probably. I don't see the relavence, though.
Python 2.3.4 (#1, Jun 13 2004, 11:21:03) [GCC 3.3.1 (cygming special)] on cygwin Type "help", "copyright", "credits" or "license" for more information.
l = [lambda:None for i in 0,1] l[0]==l[1] False l[0].func_code is l[1].func_code True
What's happened *here* is that two code objects got compiled up for the two lambdas, but they compare equal so only one goes into co_consts.
It would seem that two lambdas with no default arguments, no free variables, and identical code objects would be "equal" if we were using value comparison, rather than identity.
Yes. Cheers, mwh -- GET *BONK* BACK *BONK* IN *BONK* THERE *BONK* -- Naich using the troll hammer in cam.misc