Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Why there is a parameter named "self" for classmethod function?

18 views
Skip to first unread message

Chris Rebert

unread,
May 6, 2009, 10:55:57 PM5/6/09
to Jianchun Zhou, pytho...@python.org
On Wed, May 6, 2009 at 7:49 PM, Jianchun Zhou <jianch...@gmail.com> wrote:
> Hi, ALL:
>
> I have a sample code as bellow:
>
> #!/usr/bin/env python
>
> class Hello:
>     def __init__(self):
>         print "Hello __init__"
>     @classmethod
>     def print_hello(self):
>         print "hello"
>
> Hello.print_hello()
>
> If I move "self" parameter of print_hello away, this code fragment won't
> work.
>
> I am wondering when Hello.print_hello() executes, what value will "self" be
> asigned?

The class itself will be the value of self (hence the "class" in
"classmethod") in that case. For this reason, the parameter is
conventionally called "cls" rather than "self", to avoid confusion.

Cheers,
Chris
--
http://blog.rebertia.com

Kurt Symanzik

unread,
May 6, 2009, 11:01:44 PM5/6/09
to Jianchun Zhou, pytho...@python.org
Jianchun Zhou <jianch...@gmail.com> wrote on 2009-05-07 10:49:33 AM
+0800

> I have a sample code as bellow:
>
> #!/usr/bin/env python
>
> class Hello:
> def __init__(self):
> print "Hello __init__"
> @classmethod
> def print_hello(self):
> print "hello"
>
> Hello.print_hello()
>
> If I move "self" parameter of print_hello away, this code fragment won't
> work.
>
> I am wondering when Hello.print_hello() executes, what value will "self"
> be asigned?

The self variable above with be populated with a reference to the class,
so it would be more appropriately named cls such as:

@classmethod
def print_hello(cls):
print "hello"

But you might consider decorating the method as a static method instead
since in your example you are not using the parameter at all. A static
method would not require a parameter.

@staticmethod
def print_hello():
print "hello"

Kurt

--
Kurt Symanzik
ku...@kbsymanzik.org
Skype id: ksymanzik
http://kbsymanzik.org

Terry Reedy

unread,
May 7, 2009, 12:39:28 AM5/7/09
to pytho...@python.org
Kurt Symanzik wrote:

>
> But you might consider decorating the method as a static method instead
> since in your example you are not using the parameter at all. A static
> method would not require a parameter.
>
> @staticmethod
> def print_hello():
> print "hello"

Functions that refer to neither the class nor an instance thereof can
usually be moved outside the class altogether. Python is not Java. I
believe staticmethod() was mainly added because it is needed for
.__new__(), at least in some appearances.

tjr

Steven D'Aprano

unread,
May 7, 2009, 2:29:57 AM5/7/09
to
On Thu, 07 May 2009 00:39:28 -0400, Terry Reedy wrote:

> Functions that refer to neither the class nor an instance thereof can
> usually be moved outside the class altogether. Python is not Java. I
> believe staticmethod() was mainly added because it is needed for
> .__new__(), at least in some appearances.


Can be, but if there's reason enough to keep it with a class, there's no
reason not to. Sometimes I have a class with a few methods that share
common code, but that code happens to not include self (or cls). Since
the common code is only of interest to that class, even though it doesn't
need the instance, I factor the common code out into a method.

This would be a good candidate for a staticmethod, only due to laziness I
don't usually bother :)


--
Steven

Aaron Brady

unread,
May 7, 2009, 7:27:15 AM5/7/09
to
On May 7, 1:29 am, Steven D'Aprano

It's also useful if you want to access the function using the syntax
of attributes, as in 'self.amethod' where 'amethod' is a static
method. If I understand correctly, no bound method is created if the
function is static, and as such, the decorator can increase
performance.

> Can be, but if there's reason enough to keep it with a class, there's no
> reason not to.

That's a bit of hyperbole; the usual reasons such as code bloat,
namespace bloat, maintainability etc. all weigh against it. It's just
that the benefits weigh heavier.

There is something that is 'correct' about it IMO, that is, provides
syntax to what is valid semantics in an OO context. That may just be
another way of stating the thesis though.

Steven D'Aprano

unread,
May 8, 2009, 8:52:20 PM5/8/09
to
On Thu, 07 May 2009 04:27:15 -0700, Aaron Brady wrote:

>> Can be, but if there's reason enough to keep it with a class, there's
>> no reason not to.
>
> That's a bit of hyperbole; the usual reasons such as code bloat,
> namespace bloat, maintainability etc. all weigh against it. It's just
> that the benefits weigh heavier.

I'm not sure I understand. Whether the function is in the class or
extracted out into the module, it is exactly the same function. (Apart
from an extra level of indentation, and either an unused "self" parameter
or a @staticmethod line.) Same amount of code, same difficulty of
maintainability. Namespace bloat is also the same, the only difference
being which namespace is bloated: the class or the method.


--
Steven

Aaron Brady

unread,
May 9, 2009, 5:33:06 PM5/9/09
to
On May 8, 7:52 pm, Steven D'Aprano <st...@REMOVE-THIS-

My post was a little harsh. I meant to say that I think I got your
idea, but the form it came in was a tautology. Its form was X if not
not X. Tautologies come across as particularly low bandwidth in
writing, though they do have some content in context. I observe
people say them a lot too: 'it is what it is', 'if I want to I want
to', 'two bucks is two bucks', etc. Some of the context comes from
the partial conventional asymmetry of sentences in English between
subject and predicate (nominative and accusative), though there is
none in logic. Not to mention, 'hyperbole' isn't the word for what I
was thinking either... ahem.

The best place for such a function between those two choices can
depend on many things, some of which are matters of taste. If the
definition occurs in the class, it may be more convenient to read or
edit. That difference is pretty negligible. There is semantic
difference to inherited classes: whether you have to import the class
or the class /and/ the function. Then when it is called, the form
will be either 'class.methodA' or just 'methodA', which makes a
difference in readability (obviousness) elsewhere that it is called.

> being which namespace is bloated: the class or the method.

I think you meant 'class or module'.

Bruno Desthuilliers

unread,
May 11, 2009, 9:12:12 AM5/11/09
to
Terry Reedy a �crit :

> Kurt Symanzik wrote:
>
>>
>> But you might consider decorating the method as a static method
>> instead since in your example you are not using the parameter at all.
>> A static method would not require a parameter.
>>
>> @staticmethod
>> def print_hello():
>> print "hello"
>
> Functions that refer to neither the class nor an instance thereof can
> usually be moved outside the class altogether. Python is not Java.

Indeed. But there are a couple uses for staticmethods - one of them
being polymorphic dispatch on the receiver object. And yes, I know,
modules are objects too, but this is not always an option (legacy code,
integration with a framework etc).

0 new messages