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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
