[Jim] > We'll still need unbound builtin methods, so the concept won't > go away. In fact, the change would mean that the behavior between > builtin methods and python methods would become more inconsistent.
Actually, unbound builtin methods are a different type than bound builtin methods: >>> type(list.append) <type 'method_descriptor'> >>> type([].append) <type 'builtin_function_or_method'> >>> Compare this to the same thing for a method on a user-defined class: >>> type(C.foo) <type 'instancemethod'> >>> type(C().foo) <type 'instancemethod'> (The 'instancemethod' type knows whether it is a bound or unbound method by checking whether im_self is set.) [Phillip] > Code that currently does 'aClass.aMethod.im_func' in order to access the > function object would break, as would code that inspects 'im_self' to > determine whether a method is a class or instance method. (Although code > of the latter sort would already break with static methods, I suppose.) Right. (But I think you're using the terminology in a cunfused way -- im_self distinguishes between bould and unbound methods. Class methods are a different beast.) I guess for backwards compatibility, function objects could implement dummy im_func and im_self attributes (im_func returning itself and im_self returning None), while issuing a warning that this is a deprecated feature. [Tim] > Really? Unbound methods are used most often (IME) to call a > base-class method from a subclass, like my_base.the_method(self, ...). > It's especially easy to forget to write `self, ` there, and the > exception msg then is quite focused because of that extra bit of type > checking. Otherwise I expect we'd see a more-mysterious > AttributeError or TypeError when the base method got around to trying > to do something with the bogus `self` passed to it. Hm, I hadn't thought ot this. > I could live with that, though. Most cases would be complaints about argument counts (it gets harier when there are default args so the arg count is variable). Ironically, I get those all the time these days due to the reverse error: using super() but forgetting *not* to pass self! > Across the Python, Zope2 and Zope3 code bases, types.UnboundMethodType > is defined once and used once (believe it or not, in unittest.py). But that might be because BoundMethodType is the same type object... -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com