[Python-Dev] Should we do away with unbound methods in Py3k? (original) (raw)
Phillip J. Eby pje at telecommunity.com
Fri Nov 23 03:14:14 CET 2007
- Previous message: [Python-Dev] Should we do away with unbound methods in Py3k?
- Next message: [Python-Dev] Should we do away with unbound methods in Py3k?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: [Python-Dev] Should we do away with unbound methods in Py3k?
- Next message: [Python-Dev] Should we do away with unbound methods in Py3k?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]