What is class method?

[Bruno Desthuilliers]

Medardo Rodriguez (Merchise Group) a écrit :
> On Tue, Aug 26, 2008 at 4:10 PM, Bruno Desthuilliers
> <bdesth.quelquechose at free.quelquepart.fr> wrote:
>> In Python, there's *no* relationship between classmethods and metaclasses.
> 
> In OOP the concept of meta-class has everything to do with class
> methods, regardless if is in Python, SmallTalk or CLOSS.

Ok, I guess we're not going to agree here, since you take for granted 
that there's such a thing as a universal, language-independant 
definition of OOP concepts, and I don't (except for the two very basic 
concepts : 1/ an object is defined by an identity, a state and a 
behaviour, 2/ objects interact by sending messages to each others).

> "classmethod"
> decorator it's just a syntax sugar structure to define them. There is
> no difference (conceptually) on "method1" and "method2":
> <sample>
> class MetaXClass(type):
>     def Method1(self): pass
> class Xclass(object):
>     __metaclass__ = MetaXClass
>     @classmethod
>     def Method2(self): pass
> </sample>

There's two obvious differences : Method1 is an instance method of class 
MetaXClass, and can only be called on instances of MetaXClass, while 
Method2 is a class method of class Xclass and can be called on either 
Xclass or instances of Xclass.


>> You can drop the 'global' - there's nothing like a real global scope in
>> Python.
> 
> 
> Yes, they are. Functions defined at module level or using staticmethod
> decorator don't receive the instance as argument,

Nested functions don't receive "the" instance as argument neither...

> they are globa,

staticmethods are not, even from a Python-specific POV.

> You can study in Python:
>  * global keyword
>  * globals function

I don't think I need to study them, thanks.

But I must admit that since I disagree with you on the basis of "generic 
CS concept vs Python specific concept", I shouldn't have mentionned this 
- from a Python specific POV, functions defined at the top-level of a 
module are indeed "globals" (just like any name bound at the module 
level). OTHO, you too are now relying on the python-specific definition 
of "global" here.

>> Nope. Functions wrapped by a method object receive the instance as *first*
>> (not 'special') argument. In Python, a method is only a wrapper object
>> around the function, the class and the instance. This wrapper is built by
>> the function object's __get__ method (descriptor protocol) each time the
>> attribute is looked up.
> 
> Seriously, I'm a programmer, not a intermediate code engineer. I know
> very well how python work in its inner, but this forum is to talk
> about Python programming.

Indeed.

> Nevertheless, in some level is always call the original defined
> function, that YES, it receives the self as an argument.

Sorry, I don't understand the above sentence (seriously - no nitpicking 
here).

>> Why "theoretically speaking" ?
> 
> Why not?

Hmmm.... Because in Python, classes *are* objects, and not only from a 
theoretical POV ?-)

>>>>> isinstance(Foo, object)
>> True
> 
> That's only means that python is nice because fulfills very well the
> best OOP theory.

Which one ? Java's OOP theory ? Smalltalk's OOP theory ? CLOS OOP 
theory? Javascript's OOP theory ? Io's OOP theory ? Eiffel's OOP theory?

As far as I'm concerned, there are as many "OOP theories" as they are 
"OOP languages".

>> <ot>
>> pep08 : method names should be all_lower
>> </ot>
> 
> Not for me. I use to be consistent in being pythonic, but there are
> some few exceptions.

<ot>
Coming from the Windows world ?
</ot>

>> <ot>
>> The convention for classmethod is to name the first function argument 'cls'.
>> </ot>
> 
> I just wanted the guy who made the question, don't see other
> differences but classmethod decorator.
> Sorry!
> 
>> Nope. There's nothing like "coercion" in Python.
> 
> http://docs.python.org/ref/coercion-rules.html

Ok, you got me on this one.  What I meant was that there was nothing 
like typecasting. *And* the way the class is passed to classmethods 
called on an instance has nothing to do with coercion anyway (at least 
for commonly accepted definitions of 'coercion').

>> If you really intend to go into low-level explanations of Python's object
> 
> 
> I NEVER pretended to do that.

Sorry for this last paragraph anyway. I often tend to get too harsh, and 
regret it later. Sincerely.


Best regards, and thanks for not being as ill-tempered as I tend to.