It looks like we're in agreement to drop unbound methods and have a reasonable set or arguments around it (e.g. keep staticmethod, no changes to methods of builtin types, etc.). Do we need a PEP? It's essentially a 2-line change in funcobject.c (func_descr_get()) -- plus fixing up half a dozen or so unittests that specifically seem to test the behavior of unbound methods.
--Guido On Nov 22, 2007 6:14 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > 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. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
