A RetroSearch Logo

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

Search Query:

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

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

[Python-Dev] Should we do away with unbound methods in Py3k? [Python-Dev] Should we do away with unbound methods in Py3k?Phillip J. Eby pje at telecommunity.com
Fri Nov 23 03:14:14 CET 2007
At 01:14 PM 11/23/2007 +1300, Greg Ewing wrote:
>Guido van Rossum wrote:
> > Not quite. You can evolve an API from an instancemethod into a
> > staticmethod without changing the call sites.
>
>But is there ever any need to do that, rather than leave
>it as an instance method?

Yes.  :)  See below.


>Personally it would never have occurred to me to do that.
>If you want to be able to override it in subclasses, to
>me that's an indication that it should be an instance
>method.

Or a classmethod, or a staticmethod.

The most common use case for this (in my experience) is when you need 
a converter function or some other sort of function that's 
configurable per-instance or per-subclass.  If you are configuring it 
per-class and accessing it per-instance, and reusing an existing 
function, you have to make it a staticmethod.


>Also, what happens if you perform such a migration and
>then some subclasser later finds that he wants access to
>'self'?

Then he overrides it with a normal method.

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4