Distinguishing attributes and methods

[MonkeeSage]

On Dec 8, 4:11 pm, Bruno Desthuilliers
<bdesth.quelquech... at free.quelquepart.fr> wrote:
> MonkeeSage a écrit :
>
>
>
> > On Dec 8, 12:56 pm, Bruno Desthuilliers
> > <bdesth.quelquech... at free.quelquepart.fr> wrote:
>
> >>MonkeeSage a écrit :
>
> >>>On Dec 8, 2:10 am, Marc 'BlackJack' Rintsch <bj_... at gmx.net> wrote:
>
> >>>>On Fri, 07 Dec 2007 23:19:40 -0800, tjhnson wrote:
>
> >>>>>With properties, attributes and methods seem very similar.  I was
> >>>>>wondering what techniques people use to give clues to end users as to
> >>>>>which 'things' are methods and which are attributes.
>
> >>>>Methods are attributes.  So the decision is easy -- everything on an
> >>>>object is an attribute.  ;-)
>
> >>>>Ciao,
> >>>>       Marc 'BlackJack' Rintsch
>
> >>>I think he means callable attributes (methods) and non-callable
> >>>attributes (variables).
>
> >>callable attributes are not necessarily methods, and are still
> >>'variables' anyway.
>
> > I think it muddies the water to say that a.a() and a.a are the same
> > thing--obviously they are not.
>
> Indeed. a.a yields the object bound to name 'a' in object a, while a.a()
> yields the value returned by calling the object bound to name 'a' in
> object a.
>
> > In the common case, the first is a
> > method,
>
> Nope, it's the value returned by the call to a callable - remember that
> in Python, the parens are the call operator, so the expression a.a()
> evals to the value returned by the call to a.a - which is either the
> method object returned by the collaboration of the lookup mechanism and
> the descriptor protocol or any other possible callable object bound to
> that name or returned by the lookup mechanism for that name.

You're talking about the result of calling a.a(), I'm talking about
what the attribute "a" on the object "a" is. Which is a callable
attribute, which by definition is called a "method" in the standard
sense [1]. You can make a distinction between a "method object" and
"any other possible callable object," but I wasn't using such a
distinction, I was using the standard definition. So my point holds.
When you see a.a(), because of pythons calling convention "()" you
know that "a" is a method of object "a".

The point is that just because the attributes are "looked up the same
way" or whatever, doesn't make them the same *kind* of attribute. To
say that all attributes are the same in python muddies the water. They
are the same in a generic sense that they are attributes, but not in
their particular qualities. Like saying "all humans are the same" --
yes, in a general sense of being human. But to leave it at that is not
very helpful.

[1] http://en.wikipedia.org/wiki/Method_%28computer_science%29

> > and the second is a variable.
>
> The second is whatever the lookup mechanism will yield for this name.
>
> > Yes, you can do silly stuff,
> > such that this rule will not hold, but in general it does. Or am I
> > wrong?
>
> You're wrong. Python's "methods" are thin wrappers around an instance
> (or class) and a function. These wrappers are "built" *at lookup time*
> by the __get__ method of the function object itself when it's looked up
> as an attribute of a class, thanks to the lookup mechanism and the
> descriptor protocol.
>
> Now the fact that an attribute is callable doesn't make it a "method".
>
> Also, anyone can implement it's own callable type that will act as a
> true function - that is, implement the descriptor protocol to return a
> wrapper around the instance or class and the callable - without
> necessarily yielding an instance of types.MethodType. This is all fairly
> trivial.

Again, I am using the common definition. I understand that you can
make an attribute callable in different ways than just the standard
machinery of "def symbol(self):" (those other techniques are what I
was referring to above by "metaprogramming"). But how it is made
callable doesn't matter (nor does how it is looked up). Once it is
callable, it fits the defintion of "method" I'm using. In future, I'll
try to be clear when I'm referring to something python specific or to
a general CS concept.

> And note that none of the two above cases are necessarily "silly".
> Python exposes most of it's object model so you can hook into it and
> taylor it to your needs. This results in some constructs that may seem
> weird at first, but make sens once you understand them and learn to use
> them.

"Silly" in the sense that in this context, they only serve to show
that TIMTOWTDI, but don't actually change a callable attribute from
being a callable attribute ("method" in the general CS sense) to being
some magical "something else". For the purpose of distinguishing an
object variable (non-callable attribute) and an object method
(callable attribute), they don't add anything.

Regards,
Jordan