[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
More information about the Python-Dev mailing list
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 ]
More information about the Python-Dev mailing list