Hi,
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. With ipython, I
use tab completion all the time, but I can rarely tell from the names
alone whether it is an attribute or method.
Tips? Ideas? Best practices?
Here is one idea: Ipython should color-code the tab completion based
on attributes and methods.
26  1877 
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
On Dec 8, 2:10 am, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
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).
Regards,
Jordan
On Sat, 08 Dec 2007 00:34:06 -0800, MonkeeSage wrote:
I think he means callable attributes (methods) and non-callable
attributes (variables).
But not every callable attribute is a method.
Ciao,
Marc 'BlackJack' Rintsch
On Dec 8, 6:50 am, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
On Sat, 08 Dec 2007 00:34:06 -0800, MonkeeSage wrote:
I think he means callable attributes (methods) and non-callable
attributes (variables).
But not every callable attribute is a method.
Ciao,
Marc 'BlackJack' Rintsch
I swear, you dynamic programmers and your metaprogramming
tomfoolery! :P
Regards,
Jordan
MonkeeSage a écrit :
On Dec 8, 2:10 am, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
>>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.
On Dec 8, 12:56 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
MonkeeSage a écrit :
On Dec 8, 2:10 am, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
>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. In the common case, the first is a
method, and the second is a variable. Yes, you can do silly stuff,
such that this rule will not hold, but in general it does. Or am I
wrong?
Regards,
Jordan
On Sat, 08 Dec 2007 11:44:36 -0800, MonkeeSage wrote:
On Dec 8, 12:56 pm, Bruno Desthuilliers
>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. In the common case, the first is a
method, and the second is a variable.
No, the first is a call of `a.a` while the second is just referencing
`a.a`. And `a.a` is a "variable" no matter if it refers to a callable or
not. Variables are name to object bindings and methods are objects.
Ciao,
Marc 'BlackJack' Rintsch
On Dec 8, 4:19 am, tjhn...@gmail.com 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 verbs, attributes are nouns :)
--
Roberto Bonvallet
On Dec 8, 7:44 pm, MonkeeSage <MonkeeS...@gmail.comwrote:
I think it muddies the water to say that a.a() and a.a are the same
thing--obviously they are not.
A thing is not what it is;
A thing is what it does.
This is the Way of the Duck.
-- Basho (in his "3 extra syllables" phase)
On Dec 8, 2:51 pm, Glenn Hutchings <zond...@googlemail.comwrote:
On Dec 8, 7:44 pm, MonkeeSage <MonkeeS...@gmail.comwrote:
I think it muddies the water to say that a.a() and a.a are the same
thing--obviously they are not.
A thing is not what it is;
A thing is what it does.
This is the Way of the Duck.
-- Basho (in his "3 extra syllables" phase)
Bah. Type-by-behavior never impressed me much. And I still think that
a.a is semantically different from a.a() in python.
Regards,
Jordan
MonkeeSage a écrit :
On Dec 8, 12:56 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
>>MonkeeSage a écrit :
>>>On Dec 8, 2:10 am, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
>>>>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.
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.
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.
MonkeeSage a écrit :
On Dec 8, 2:51 pm, Glenn Hutchings <zond...@googlemail.comwrote:
>>On Dec 8, 7:44 pm, MonkeeSage <MonkeeS...@gmail.comwrote:
>>>I think it muddies the water to say that a.a() and a.a are the same
thing--obviously they are not.
A thing is not what it is;
A thing is what it does.
This is the Way of the Duck.
-- Basho (in his "3 extra syllables" phase)
Bah. Type-by-behavior never impressed me much. And I still think that
a.a is semantically different from a.a() in python.
It is indeed and very obviously semantically different, and no one said
it wasn't. The first is an attribute lookup, the second is an attribute
lookup followed by a call. Now this doesn't make the attribute lookup
part different in both cases...
In article <47***********************@news.free.fr>,
Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:
MonkeeSage a écrit :
On Dec 8, 2:51 pm, Glenn Hutchings <zond...@googlemail.comwrote:
>On Dec 8, 7:44 pm, MonkeeSage <MonkeeS...@gmail.comwrote:
I think it muddies the water to say that a.a() and a.a are the same
thing--obviously they are not.
A thing is not what it is;
A thing is what it does.
This is the Way of the Duck.
-- Basho (in his "3 extra syllables" phase)
Bah. Type-by-behavior never impressed me much. And I still think that
a.a is semantically different from a.a() in python.
It is indeed and very obviously semantically different, and no one said
it wasn't. The first is an attribute lookup, the second is an attribute
lookup followed by a call. Now this doesn't make the attribute lookup
part different in both cases...
There are a very few corner cases were you can leave the ()'s out. For
example, you can do;
raise Exception
or
raise Exception()
but stuff like that is very much a wart in the language syntax.
Roy Smith a écrit :
In article <47***********************@news.free.fr>,
Bruno Desthuilliers <bd*****************@free.quelquepart.frwrote:
>>MonkeeSage a écrit :
(snip)
>>>Bah. Type-by-behavior never impressed me much. And I still think that
a.a is semantically different from a.a() in python.
It is indeed and very obviously semantically different, and no one said
it wasn't. The first is an attribute lookup, the second is an attribute
lookup followed by a call. Now this doesn't make the attribute lookup
part different in both cases...
There are a very few corner cases were you can leave the ()'s out.
You can leave them out wherever you want - it's just that it won't do
the same thing !-)
For
example, you can do;
raise Exception
or
raise Exception()
The context is somewhat different...
but stuff like that is very much a wart in the language syntax.
The syntax is
raise [<expression>[, <expression>,[ <expression>]]]
which can be used as either
raise <type>[, <value>[, <traceback>]]
or
raise <instance>[, None[, <traceback>]] http://docs.python.org/ref/raise.html
You can call it a wart, but at least it's a well defined one - that is,
the first expression must eval to either an Exception type or an
Exception instance. So the 'optional' use of the call operator here has
nothing to do with it's mandatory use to actually call a function.
On Dec 8, 4:11 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
MonkeeSage a écrit :
On Dec 8, 12:56 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
>MonkeeSage a écrit :
>>On Dec 8, 2:10 am, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
>>>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_...ter_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
Op Sun, 09 Dec 2007 12:44:46 -0800, schreef MonkeeSage:
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.
Well, I guess Python is a language for human being... ;-)
To conclude this discussion:
* in Python, methods are attributes
* in Ruby, attributes are methods
--
JanC
On Sun, 09 Dec 2007 12:44:46 -0800, MonkeeSage wrote:
On Dec 8, 4:11 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
>MonkeeSage a écrit :
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".
No you don't know that. It's only a method of object `a` if it is really
a method bound to object `a` and not just a "data attribute" that happens
to be callable.
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.
Your definition of "method" is a bit odd then. The general CS sense of
"method" requires the method to be bound to the object and not just be a
random callable. Let's see an example:
In [469]: a = collections.defaultdict(int)
In [470]: callable(a.default_factory)
Out[470]: True
In [471]: a.default_factory(42)
Out[471]: 42
`a.default_factory` is callable but hardly a method of `a` or `defaultdict`
but a "data attribute" that happens to be callable.
Ciao,
Marc 'BlackJack' Rintsch
MonkeeSage a écrit :
On Dec 8, 4:11 pm, Bruno Desthuilliers
(snip)
>>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()
No, I'm talking about the result of calling a.a - which is what a.a()
means !-)
Jordan, I of course understand what you mean - but the way you express
it is not coherent with how Python works. In Python, the expression
a.a() *is* the result of calling a.a, period.
>, I'm talking about
what the attribute "a" on the object "a" is.
which is the value of expression "a.a". Whether this expression evals to
a callable object or not, and wether this callable object is actually a
method object or not is another question, mostly unrelated with the
meaning of expression 'a.a'.
Which is a callable
attribute, which by definition is called a "method" in the standard
sense [1].
Still not. The fact that an attribute is callable doesn't make it a method.
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.
Which standard definition ? Obviously not Python's standard definition
anyway !-)
So my point holds.
When you see a.a(), because of pythons calling convention "()" you
know that "a" is a method of object "a".
No you don't. You know that a.a is callable, period.
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.
<mode="stubborn">
Yes it does : they are all of kind 'object' !-)
</mode>
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.
Obviously not - but this is true for all known OOPL. Now from a
technical POV, there are no separate slots, no compiler-or-interpreter
special processing, nor nothing else special about 'methods', no special
type, etc - the storage and lookup mechanisms are *exactly* the same for
*all* attributes (leaving special features like __slots__ aside). All
the "magic" in 'methods' is handled by the way the function type
implements the descriptor protocol, and this can be reproduced by any
other type, because it's just *one* possible use of lookup hooks (+, in
this case, callable objects) - another possible use being the property
type. IOW, what makes the difference is the specific implementation of
the attribute's class, *not* the generic attribute storage/lookup mechanism.
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_...ter_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.
This "common definition" is obviously not applicable to each and every
language - at least when it comes to implementation !-)
Mays I remind you that the OP question was about "how to distinguish
methods from attributes". And the answer is that given Python's object
model and implementation, there's no clear, definitive and unambiguous
way to do so.
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).
The fact is that it does matter, because it's the lookup mechanism that
implements the hook used by functions to return methods when they are
used as class attributes. And it also matters because *all* this
behaviour can be reproduced without extending the function type nor
using the method type, so you can't even rely on typechecking to
distinguish a callable attribute from what is commonly known as a a method.
Once it is
callable, it fits the defintion of "method" I'm using.
Still not. May I remind you that the class is a callable attribute of an
object ? And that when used as *instance* attributes, functions remain
plain functions ? And that a class attribute can be callable without
implementing the lookup hook that would yield a method object ?
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)
This is exactly what I'm trying to explain here : in Python, callable
attribute != method.
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.
By your definition, the class of an object is a method. I'll let you
think about it...
It seems that I've got a short-circuit somewhere here. I understand
that everything is an object and the the storage/lookup system is
object-agnostic, and that it is only the descriptors (or "tags" as I
called them generically) that determine how an attribute is bound,
whether it is bound at all, whether it is even callable, and so forth.
So, when I say that all callable attributes (or to be more precise,
all callable attributes bound to objects other than toplevel) are
"methods," what am I missing?
You said "the difference [between a callable attribute and a method]
is the specific implementation of the attribute's class"...but this
almost sounds like type-by-primitive (a method is a method when it
derives from a certain base class), or type-by-behavior (a method is a
method when it behaves in a certain way, e.g., responds in a certain
way to a query). Is this correct? Shouldn't it be type-by-capability/
interface--i.e., it implements the protocol of a callable, therefore,
formally, it is not meaningfully different from any other callable
(quacks like a duck and all)?
I guess what I'm asking is, in what way is a "method" (or "function")
semantically different from a home-brewed callable I concoct and bind
to an object (or toplevel)? What is the distinction that I'm missing?
Ps. wrt your last comment, isn't a class object in essence a factory
method?
Regards,
Jordan
MonkeeSage a écrit :
It seems that I've got a short-circuit somewhere here. I understand
that everything is an object and the the storage/lookup system is
object-agnostic, and that it is only the descriptors (or "tags" as I
called them generically)
"descriptor" is a protocol - an interface if you prefer. It's a way for
a class attribute to hook into the lookup mechanism, and it's
implemented by the property type - to provide a basic support for
computed attributes - and the function type - to provide the machinery
that turns a function into a method.
that determine how an attribute is bound,
whether it is bound at all, whether it is even callable,
An object is callable if it implement the __call__ method (for the
commonly admitted definition of 'method' !-).
and so forth.
So, when I say that all callable attributes (or to be more precise,
all callable attributes bound to objects other than toplevel)
You mean "other than a module" ?
are
"methods," what am I missing?
All callable attributes that are either bound to an instance or don't
implement the descriptor protocol the way the function type do.
You said "the difference [between a callable attribute and a method]
is the specific implementation of the attribute's class"...but this
almost sounds like type-by-primitive
It isn't.
(a method is a method when it
derives from a certain base class), or type-by-behavior (a method is a
method when it behaves in a certain way, e.g., responds in a certain
way to a query).
Bingo.
Is this correct? Shouldn't it be type-by-capability/
interface--i.e., it implements the protocol of a callable, therefore,
formally, it is not meaningfully different from any other callable
(quacks like a duck and all)?
The answer is in how the function type implements the descriptor
protocol. For an attribute to "become" a method when looked up, this
attribute has to implement the descriptor protocol so that it's __get__
method returns either a BoundMethod (or any equivalent) when looked up
on the instance and an UnboundMethod (or any equivalent) when looked up
on the class (I'll save you the details about classmethods etc).
Now since the method type is mostly trivial to implement, the fact that
an attribute lookup doesn't return an instance of Method doesn't
necessarily imply it's not one - so the truth is that an attribute is a
method if it behaves like one !-)
I guess what I'm asking is, in what way is a "method" (or "function")
Python's 'methods' are really thin wrappers around an object, it's class
and a function. In the common use case, one of these wrappers is
instanciated each time you lookup a function that's a class attributes.
semantically different from a home-brewed callable I concoct and bind
to an object (or toplevel)? What is the distinction that I'm missing?
Implement your own callable that doesn't implement the descriptor
protocol, bind it to a class, instanciate your class, lookup this
attribute. You'll get the original attribute, not a method. Or bind a
function to an *instance*, and look it up - here again, you wont get a
method, but the original function object.
Now you can of course label this a static method if you want !-)
If you want a custom callable to be usable as a method, you have to
implement the descriptor protocol like the function type do.
Ps. wrt your last comment, isn't a class object in essence a factory
method?
Not quite - even if you can use it that way. In fact, the real factory
method is the __new__ method of the class - that is, the proper constructor.
A class object is an object that is responsible for:
* creating instances of itself (and as such, it is indeed a factory -
but a factory object, not a factory method)
* providing class attributes and mro to these instances (lookup rules
here: a name not found in the instance's __dict__ will be looked up in
the class, then in classes in the mro - unless of course the class
implements __getattr__ or __getattribute__, in which case all bets are
off).
caveat : all this describes the 'new-style' object model. The 'classic'
('old-style') object model works a bit differently.
Regards,
Jordan
On Mon, 10 Dec 2007 03:56:10 -0800, MonkeeSage wrote:
So, when I say that all callable attributes (or to be more precise, all
callable attributes bound to objects other than toplevel) are "methods,"
what am I missing?
Everything that isn't a method but is callable.
class Callable(object):
def __call__(self):
return oct(id(self))
class Foo(object):
aclass = type('Parrot', (object,), {})
atype = int
ainstance = Callable()
afunction = None # this is tricky...
def __init__(self): # a method
self.afunction = lambda n: n+1
--
Steven
On Dec 10, 7:19 am, Bruno Desthuilliers <bruno.
42.desthuilli...@wtf.websiteburo.oops.comwrote:
MonkeeSage a écrit :
It seems that I've got a short-circuit somewhere here. I understand
that everything is an object and the the storage/lookup system is
object-agnostic, and that it is only the descriptors (or "tags" as I
called them generically)
"descriptor" is a protocol - an interface if you prefer. It's a way for
a class attribute to hook into the lookup mechanism, and it's
implemented by the property type - to provide a basic support for
computed attributes - and the function type - to provide the machinery
that turns a function into a method.
that determine how an attribute is bound,
whether it is bound at all, whether it is even callable,
An object is callable if it implement the __call__ method (for the
commonly admitted definition of 'method' !-).
and so forth.
So, when I say that all callable attributes (or to be more precise,
all callable attributes bound to objects other than toplevel)
You mean "other than a module" ?
are
"methods," what am I missing?
All callable attributes that are either bound to an instance or don't
implement the descriptor protocol the way the function type do.
You said "the difference [between a callable attribute and a method]
is the specific implementation of the attribute's class"...but this
almost sounds like type-by-primitive
It isn't.
(a method is a method when it
derives from a certain base class), or type-by-behavior (a method is a
method when it behaves in a certain way, e.g., responds in a certain
way to a query).
Bingo.
Is this correct? Shouldn't it be type-by-capability/
interface--i.e., it implements the protocol of a callable, therefore,
formally, it is not meaningfully different from any other callable
(quacks like a duck and all)?
The answer is in how the function type implements the descriptor
protocol. For an attribute to "become" a method when looked up, this
attribute has to implement the descriptor protocol so that it's __get__
method returns either a BoundMethod (or any equivalent) when looked up
on the instance and an UnboundMethod (or any equivalent) when looked up
on the class (I'll save you the details about classmethods etc).
Now since the method type is mostly trivial to implement, the fact that
an attribute lookup doesn't return an instance of Method doesn't
necessarily imply it's not one - so the truth is that an attribute is a
method if it behaves like one !-)
I guess what I'm asking is, in what way is a "method" (or "function")
Python's 'methods' are really thin wrappers around an object, it's class
and a function. In the common use case, one of these wrappers is
instanciated each time you lookup a function that's a class attributes.
semantically different from a home-brewed callable I concoct and bind
to an object (or toplevel)? What is the distinction that I'm missing?
Implement your own callable that doesn't implement the descriptor
protocol, bind it to a class, instanciate your class, lookup this
attribute. You'll get the original attribute, not a method. Or bind a
function to an *instance*, and look it up - here again, you wont get a
method, but the original function object.
Now you can of course label this a static method if you want !-)
If you want a custom callable to be usable as a method, you have to
implement the descriptor protocol like the function type do.
Ps. wrt your last comment, isn't a class object in essence a factory
method?
Not quite - even if you can use it that way. In fact, the real factory
method is the __new__ method of the class - that is, the proper constructor.
A class object is an object that is responsible for:
* creating instances of itself (and as such, it is indeed a factory -
but a factory object, not a factory method)
* providing class attributes and mro to these instances (lookup rules
here: a name not found in the instance's __dict__ will be looked up in
the class, then in classes in the mro - unless of course the class
implements __getattr__ or __getattribute__, in which case all bets are
off).
caveat : all this describes the 'new-style' object model. The 'classic'
('old-style') object model works a bit differently.
Regards,
Jordan
Thank you kindly Bruno. You're answers have been very informative. I
thought I understand how python was operating, but I see that I have
some misconceptions. I honestly did read through the reference manual
when I started learning python a couple years ago, but I'm not the
most patient person by nature, and it seems that I was so happy with a
shiny new language, that I imported some foreign concepts into the
picture and glossed over many of the details of pythons object model.
I'm going to give the "Data Model" section a thorough going-over
again, and try to pay more attention this time(!) ;)
Just as a side-note, it's interesting that even through my
misunderstandings I've been able to use python to great effect (I've
translated several fairly complex apps to python, using decorators,
CPS and other fairly "advanced" techniques, and it "Just Worked").
Heh. Nice language. :)
Anyway, thanks again for your time an patience.
Regards,
Jordan
MonkeeSage a écrit :
On Dec 10, 7:19 am, Bruno Desthuilliers <bruno.
(snip)
I'm going to give the "Data Model" section a thorough going-over
again, and try to pay more attention this time(!) ;)
Also make sure you read the docs about new-style classes, the descriptor
protocol and metaclasses.
Just as a side-note, it's interesting that even through my
misunderstandings I've been able to use python to great effect (I've
translated several fairly complex apps to python, using decorators,
CPS and other fairly "advanced" techniques, and it "Just Worked").
Heh. Nice language. :)
Indeed !-)
Anyway, thanks again for your time an patience.
Thanks *you* for your patience - I'm certainly not the best teacher here !-)
Jan Claeys a écrit :
Op Sun, 09 Dec 2007 12:44:46 -0800, schreef MonkeeSage:
>>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.
Well, I guess Python is a language for human being... ;-)
To conclude this discussion:
* in Python, methods are attributes
* in Ruby, attributes are methods
And this is probably the most sensible post in this thread !-)
MonkeeSage <Mo********@gmail.comwrote:
It seems that I've got a short-circuit somewhere here. I understand
that everything is an object and the the storage/lookup system is
object-agnostic, and that it is only the descriptors (or "tags" as I
called them generically) that determine how an attribute is bound,
whether it is bound at all, whether it is even callable, and so forth.
So, when I say that all callable attributes (or to be more precise,
all callable attributes bound to objects other than toplevel) are
"methods," what am I missing?
You said "the difference [between a callable attribute and a method]
is the specific implementation of the attribute's class"...but this
almost sounds like type-by-primitive (a method is a method when it
derives from a certain base class), or type-by-behavior (a method is a
method when it behaves in a certain way, e.g., responds in a certain
way to a query). Is this correct? Shouldn't it be type-by-capability/
interface--i.e., it implements the protocol of a callable, therefore,
formally, it is not meaningfully different from any other callable
(quacks like a duck and all)?
I guess what I'm asking is, in what way is a "method" (or "function")
semantically different from a home-brewed callable I concoct and bind
to an object (or toplevel)? What is the distinction that I'm missing?
--8<---------------cut here---------------start------------->8---
#!/usr/bin/env python
class Foo(object):
def __init__(self):
def func(*args):
return str(args)
self.a=func
def b(*args):
return str(args)
@classmethod
def c(*args):
return str(args)
f=Foo()
print f.a(1) # just a callble
print f.b(1) # an instance method
print f.c(1) # a class method
--8<---------------cut here---------------end--------------->8---
Florian
--
<http://www.florian-diesch.de/>
-----------------------------------------------------------------------
** Hi! I'm a signature virus! Copy me into your signature, please! **
-----------------------------------------------------------------------
MonkeeSage wrote:
what am I missing?
To my eyes, when you write:
>I think it muddies the water to say that a.a() and a.a are the same
thing--obviously they are not. In the common case, the first is a
method, and the second is a variable.
What you are most obviously missing is what's shown by
b=a.a
b()
IOW I am tempted to make the prediction that you never use bound methods as
values :)
Cheers, BB This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Matthew Bell |
last post by:
Hi,
I've got a question about whether there are any issues with directly
calling attributes and/or methods of a threaded class instance. I
wonder if someone could give me some advice on this.
...
|
by: Alexander Kervero |
last post by:
Hi ,today i was reading diveinto python book,in chapter 5 it has a very
generic module to get file information,html,mp3s ,etc.
The code of the example is here :...
|
by: Steve - DND |
last post by:
Is it possible to do something like what this chapter excerpt shows, except
for just a regular non-remoting bunch of code?
http://www.microsoft.com/mspress/books/sampchap/6172a.asp
The reason...
|
by: Mark R. Dawson |
last post by:
Hi all,
I am trying to get custom attributes from a property. I can do this if I
pass in the name of the property i.e. "Name" to the reflection methods, but
if I pass in set_Name which is what...
|
by: Thomas Girod |
last post by:
Hi there.
I'm trying to get a list of attributes from a class. The dir() function
seems to be convenient, but unfortunately it lists to much - i don't
need the methods, neither the built-in...
|
by: vivekian |
last post by:
Hi ,
I am moving on from C++ to C# . Though have understood how attributes
work , still dont understand what need do the fullfil ? Where should
they be used ? What are their advantages ? some...
|
by: redefined.horizons |
last post by:
I've been reading about Python Classes, and I'm a little confused about
how Python stores the state of an object. I was hoping for some help.
I realize that you can't create an empty place holder...
|
by: prabhupr |
last post by:
Hi Folks
I was reading this article
(http://www.dotnetbips.com/articles/displayarticle.aspx?id=32) on
"Custom Attribute", written by Bipin.
The only thing I did not understand in this article...
|
by: Pedro Werneck |
last post by:
Hi all
I noticed something strange here while explaining decorators to someone.
Not any real use code, but I think it's worth mentioning.
When I access a class attribute, on a class with a...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
