[Guido] > > Here's a patch that gets rid of unbound methods, as > > discussed here before. A function's __get__ method > > now returns the function unchanged when called without > > an instance, instead of returning an unbound method object.
[Greg] > I thought the main reason for existence of unbound > methods (for user-defined classes, at least) was so that > if you screw up a super call by forgetting to pass self, > or passing the wrong type of object, you get a more > helpful error message. Yes, Tim reminded me of this too. But he said he could live without it. :-) > I remember a discussion about this some years ago, in > which you seemed to think the ability to produce this > message was important enough to justify the existence > of unbound methods, even though it meant you couldn't > easily have static methods (this was long before > staticmethod() was created). > > Have you changed your mind about that? After all those years, I think the added complexity of unbound methods doesn't warrant having the convenience of the error message. > Also, surely unbound methods will still have to exist > for C methods? Otherwise there will be nothing to ensure > that C code is getting the object type it expects for > self. No, C methods have their own object type for that (which is logically equivalent to an unbound method). But there was a use case for unbound methods having to do with C methods of classic classes, in the implementation of built-in exceptions. Anyway, it's all moot because I withdrew the patch, due to the large amount of code that would break due to the missing im_class attribute -- all fixable, but enough not to want to break it all when 2.5 comes out. So I'm salting the idea up for 3.0. -- --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
