[Python-Dev] Should we do away with unbound methods in Py3k?
Guido van Rossum
guido at python.org
Fri Nov 23 05:19:57 CET 2007
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 <pje at telecommunity.com> 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 at 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/)
More information about the Python-Dev
mailing list