[Python-Dev] Getting rid of unbound methods: patch available
Guido van Rossum
gvanrossum at gmail.com
Fri Jan 28 23:45:00 CET 2005
[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/)
More information about the Python-Dev
mailing list