[Python-Dev] Should we do away with unbound methods in Py3k?
Guido van Rossum
guido at python.org
Thu Nov 22 04:15:10 CET 2007
On Nov 21, 2007 4:58 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> If I understand correctly, this would negate the need for staticmethod()
> when accessing the function via the class (and not instances) since the
> main effect of that is to prevent the wrapping. (And since I consider
> instance.somestaticmeth() as even less idiomatic Python that
> class.somestaticmeth(), I should think staticmethod then could go also.)
Not quite. You can evolve an API from an instancemethod into a
staticmethod without changing the call sites. Also (unlike Java or
C++) you can override a staticmethod, and self.somestaticmeth() will
look it up in self.__class__.
> This change would certainly reinforce the idea that in Python, methods are
> just functions with a special access. It might quiet the calls for
> 'implicit' self.
Doubt it. :-)
> It would make Python slightly easier to learn, I think, since the reason
> for unbound method wrapping is not obvious. From what you said, it is a
> sacrifice of speed for safety. But this is the only place I can think of
> where an argument type-check is automatically applied to user-written
> functions.
I think historically we didn't always have unbound methods; I believe
I introduced them (in the 1.x days I think) to catch what was mostly a
hypothetical error case.
> So, +whatever from me for making Python slightly simpler.
Thanks. I like this better than changing the definition of isinstance().
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list