[Python-3000] Removing 'self' from method definitions
Ian Bicking
ianb at colorstudy.com
Thu Apr 13 19:59:47 CEST 2006
Gustavo Niemeyer wrote:
>>The traditional way of calling superclass methods and getting an unbound
>>method should still work. It just won't be symmetric with the way the
>>functions are defined. Since this is not the typical way methods are
>>called, it seems reasonable.
>
>
> Using "obj.some_method(blah)" when something is defined as
> "def some_method(self, blah):" is easy to understand since someone
> may be filling the "self" parameter for you (partial functions
> anyone?), but using "Class.some_method(self, blah)" when something
> is defined as "def some_method(blah):" looks bizarre.
Class.some_method(self, blah) seems like a corner case. How often do
you do that? If it is calling a superclass method, then super(Class,
self).some_method() should be used (or even better, a more pleasant
syntax for super -- which seems more feasible to implement given
out-of-bad communication into the function about how it is being called).
> I've programmed for a long time in other languages where "self" is
> implicit, and have also programmed in Python for many years
> using the explicit "self". The explicit "self" in Python completely
> matches with the features of the language, IMO. Making it implicit
> would be a huge mistake, and one that would most probably seem
> absurd if you have used Python for a while and haven't had contact
> with other languages that introduce a very magic "self" in some
> contexts of your program.
I have been using Python for a while, and it does not feel absurd to me.
Note that I am not suggesting that self be removed anywhere but from the
signature of the method definition.
My own interpretation of self-related criticism is that people get
bothered with all the "self"s from their experience with other
languages, but the self in the signature (and the miscount of arguments
in TypeError exceptions) keeps them from feeling completely as ease with
the new way of working. They project that unease onto all use of
"self", and then we dismiss them for just trying to make Python into
another language when they propose removing many of the uses of self.
That is, their interpretation of *why* they are dissatisfied may not be
entirely correct, but underlying that dissatisfaction are real issues.
I think this is a common occurance when studying usability -- users can
identify problem areas, but when they reflect on what exactly those
problems are they often misinterpret their experience.
Anyway, maybe it's possible to experiment with this right now with some
metaclass cleverness.
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Python-3000
mailing list