Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: > But you acknowledge they are really the same method attached to > different classes, right? The notion of "unbound method" is mostly an > implementation detail. The term occurs only 4 times in the whole Python > documentation (according to Google). And in py3k they are gone. (*)
It's the same function attached to two different classes. I don't really buy the "implementation detail" argument - if Guido says it, then I don't have much choice but to accept it, but I'm going to argue about it with anyone else. :) In this case, I'd say it's definitely not an implementation detail because it has major consequences visible to applications. If I get method x from class A and try to call it with an instance of class B, then it's going to break. I have to know about this behavior in order to write a program that works. Py3k may be different, but I'm not going to talk about Py3k here because I'm only interested in the Python 2.x behavior. > Moreover, you say you want them to compare unequal because you > *explicitly* want the same method called separately for each class it is > defined on. Is there anything preventing you to have a set of (class, > method) tuples instead? Because it sounds like the logical thing to do > in your case. I could do that. I probably will, too, since this code needs to work on Python 2.3 through Python 2.5. I still want to make Python 2.6 better, though. It seems to me that an unbound method is already effectively a tuple of (class, function) - it has a reference to both of those. Requiring applications to tie it up with a class again is just redundant. > "Trust" is a strong word. You can trust the comparison operator if you > agree with its semantics, you cannot trust it if you want different > semantics. But that doesn't mean it is generally trustworthy or > untrustworthy. You're right. "trust" was a bad word to use there. > I don't think there are lots of use cases for comparing *unbound* > methods. One such use case is checking for redefinition of inherited > methods, and the current __eq__ semantics look fine for that. This use-case is already satisfied though - if an application wants to see if the function is the same, then the application can compare the im_func attribute of the method objects. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3500> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
