[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