>In article <0dc26f12-2541-4d41-8678-4fa53f347...@g9g2000yqb.googlegroups.com> T. Goodchild asked, in part: >>... One of the things that bugs me is the requirement that all class >>methods have 'self' as their first parameter.
In article <4e5e5628$0$29977$c3e8da3$54964...@news.astraweb.com> Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: [Comprehensive reply, noting that these are actually instance methods, and that there are class and static methods as well]: >Python does have class methods, which receive the class, not the instance, >as the first parameter. These are usually written something like this: > >class K(object): > @classmethod > def spam(cls, args): > print cls # always prints "class K", never the instance > >Just like self, the name cls is a convention only. Class methods are usually >used for alternate constructors. > >There are also static methods, which don't receive any special first >argument, plus any other sort of method you can invent, by creating >descriptors... but that's getting into fairly advanced territory. ... [rest snipped] I am not sure whether T. Goodchild was asking any of the above or perhaps also one other possible question: if an instance method is going to receive an automatic first "self" parameter, why require the programmer to write that parameter in the "def"? For instance we *could* have: class K(object): def meth1(arg1, arg2): self.arg1 = arg1 # self is "magically available" self.arg2 = arg2 @classmethod def meth2(arg): use(cls) # cls is "magically available" and so on. This would work fine. It just requires a bit of implicit sneakiness in the compiler: an instance method magically creates a local variable named "self" that binds to the invisible first parameter, and a class method magically creates a local variable named "cls" that binds to the invisible first parameter, and so on. Instead, we have a syntax where you, the programmer, write out the name of the local variable that binds to the first parameter. This means the first parameter is visible. Except, it is only visible at the function definition -- when you have the instance and call the instance or class method: black_knight = K() black_knight.meth1('a', 1) black_knight.meth2(2) the first parameters (black_knight, and black_knight.__class__, respectively) are magic, and invisible. Thus, Python is using the "explicit is better than implicit" rule in the definition, but not at the call site. I have no problem with this. Sometimes I think implicit is better than explicit. In this case, there is no need to distinguish, at the calls to meth1() and meth2(), as to whether they are "class" or "instance" methods. At the *calls* they would just be distractions. At the *definitions*, they are not as "distraction-y" since it is important to know, during the definition, whether you are operating on an instance (meth1) or the class itself (meth2), or for that matter on neither (static methods). One could determine this from the absence or presence of "@classmethod" or "@staticmethod", but the minor redundancy in the "def" statement seems, well, minor. Also, as a bonus, it lets you obfuscate the code by using a name other than "self" or "cls". :-) -- In-Real-Life: Chris Torek, Wind River Systems Intel require I note that my opinions are not those of WRS or Intel Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: gmail (figure it out) http://web.torek.net/torek/index.html
-- http://mail.python.org/mailman/listinfo/python-list