Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > The reason I noticed this is that since they compare and hash equal, if > you put two such methods into a set, you end up with a set with one > method. Currently, this is preventing me from running two test methods > because the method itself is defined on a base class and two subclasses > which customize several other methods inherit it. I can only run one > test at a time.
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. (*) 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. > Having them compare unequal means you can't actually trust unbound > method comparison, nor using unbound methods as keys in a dictionary. "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. Really, this is the same as with numbers: 'b' There are probably use cases where the above is annoying. But, conversely, there are probably use cases where a stricter behaviour would be annoying too. > This means some other mapping structure is required if you want to keep > around a bunch of methods and arguments to pass to them. I disagree. The general use case of keeping a bunch of callables with their respective arguments implies storing bound, not unbound, methods. (how often do you feed an unbound method to an addCallback() ?) > It also means > that any time you want to check two methods against each other with the > goal of eventually calling one or both of them, you need to use > something other than `==ยด. 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. (*) Python 3.0b2+ (py3k, Jul 29 2008, 20:37:34) [GCC 4.3.1 20080626 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... def f(): pass ... >>> type(A.f) <class 'function'> >>> a = A() >>> type(a.f) <class 'method'> >>> def g(): pass ... >>> class B: ... g = g ... >>> B.g is g True _______________________________________ 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
