[Python-Dev] Should we do away with unbound methods in Py3k? (original) (raw)

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