Medardo Rodriguez (Merchise Group) a écrit :
On Tue, Aug 26, 2008 at 4:10 PM, Bruno Desthuilliers
<[EMAIL PROTECTED]> 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.
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to