RetroSearch Browse

Thu Nov 22 04:15:10 CET 2007 · https://mail.python.org/pipermail/python-dev/2007-November/075291.html

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/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-November/075291.html below:

[Python-Dev] Should we do away with unbound methods in Py3k?