On Tue, Jun 28, 2011 at 10:30:14AM +1000, Nick Coghlan wrote:
> Rather than fighting that convention, we should probably just confront
> the ambiguity head on and update
> http://docs.python.org/dev/glossary.html#term-attribute to describe
> both uses of the term (and add a separate entry for "dat
On Tue, Jun 28, 2011 at 06:28, Nick Coghlan wrote:
> On Tue, Jun 28, 2011 at 10:56 PM, Michael Foord
> wrote:
> > I don't think "data attributes" is clear or precise. Is a property a data
> > attribute (well it depends how it is implemented and what it does), is a
> > staticmethod a data attribu
On 6/28/2011 11:35 AM, Michael Foord wrote:
On 28/06/2011 16:23, Terry Reedy wrote:
So-called 'staticmethods' are not really methods either, but are class
function attributes that are just functions and not treated as
methods. The decorator that negates normal method treatment
could/should hav
On 6/28/2011 9:20 AM, Steven D'Aprano wrote:
>>> class C:
... def method(self, x):
... return x+1
...
>>> c = C()
>>> c.method = types.MethodType(lambda self, x: x+101, c)
types.MethodType creates a bound method, not a method. A bound method is
a partial or curried function, which is to sa
On Tue, Jun 28, 2011 at 7:20 AM, Steven D'Aprano wrote:
> Michael Foord wrote:
>
>> What do you mean by "instances can have methods as instance attributes"?
>> Once you attach a bound method directly to an instance it becomes a slightly
>> different beast I think. (On top of which that is pretty r
On 28/06/2011 16:23, Terry Reedy wrote:
On 6/28/2011 7:51 AM, R. David Murray wrote:
Also, instances can have methods as instance attributes.
Functions that are instance attributes do not act like methods
(instance.func() does not automagically turn instance in the first arg
of func) and ha
On Tue, Jun 28, 2011 at 5:35 AM, Michael Foord
wrote:
>
> Well, they're *usually* implemented as methods and backed by a real instance
> attribute. Usually (but not always) it makes more sense (IME) to group them
> with methods. The fact that they're *accessed* as an attribute is the
> uninteresti
On 6/28/2011 7:51 AM, R. David Murray wrote:
Also, instances can have methods as instance attributes.
Functions that are instance attributes do not act like methods
(instance.func() does not automagically turn instance in the first arg
of func) and have never, to my knowledge, been called me
On Tue, Jun 28, 2011 at 11:27 PM, Michael Foord
wrote:
> Technically also via __getattribute__ when overridden.
Since object.__getattribute__ is the hook that implements the entire
attribute lookup protocol, *all* attributes are technically retrieved
via __getattribute__ (which is why overriding
On Tue, Jun 28, 2011 at 10:56 PM, Michael Foord
wrote:
> I don't think "data attributes" is clear or precise. Is a property a data
> attribute (well it depends how it is implemented and what it does), is a
> staticmethod a data attribute (no - but then Tres' question - it isn't a
> normal method e
On 28/06/2011 14:20, Steven D'Aprano wrote:
Michael Foord wrote:
What do you mean by "instances can have methods as instance
attributes"? Once you attach a bound method directly to an instance
it becomes a slightly different beast I think. (On top of which that
is pretty rare behaviour.)
>>
On 28/06/2011 13:56, Michael Foord wrote:
On 28/06/2011 13:31, Nick Coghlan wrote:
On Tue, Jun 28, 2011 at 8:54 PM, Michael Foord
wrote:
The problem with "data attributes" is that it doesn't mean
*anything*, which
I suppose is useful for invented terminology, but it means it
doesn't convey
a
Michael Foord wrote:
What do you mean by "instances can have methods as instance attributes"?
Once you attach a bound method directly to an instance it becomes a
slightly different beast I think. (On top of which that is pretty rare
behaviour.)
>>> class C:
... def method(self, x):
...
On 28/06/2011 13:31, Nick Coghlan wrote:
On Tue, Jun 28, 2011 at 8:54 PM, Michael Foord
wrote:
The problem with "data attributes" is that it doesn't mean *anything*, which
I suppose is useful for invented terminology, but it means it doesn't convey
anything precise to those who haven't heard t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/28/2011 06:44 AM, Fred Drake wrote:
> On Tue, Jun 28, 2011 at 2:33 AM, Nick Coghlan wrote:
>> The two terms I've got out of this thread are "callable attributes"
>> (instance/static/class methods, etc) and "data attributes" (everything
>> else).
On Tue, Jun 28, 2011 at 8:54 PM, Michael Foord
wrote:
> The problem with "data attributes" is that it doesn't mean *anything*, which
> I suppose is useful for invented terminology, but it means it doesn't convey
> anything precise to those who haven't heard the term before. If it becomes
> widely
On 28/06/2011 12:51, R. David Murray wrote:
On Tue, 28 Jun 2011 11:54:39 +0100, Michael Foord
wrote:
On 28/06/2011 11:44, Fred Drake wrote:
But "callable attributes" aren't the same thing as methods; most are methods,
but not all. Sometimes, they're data used by the object. The fact that
da
On Tue, 28 Jun 2011 11:54:39 +0100, Michael Foord
wrote:
> On 28/06/2011 11:44, Fred Drake wrote:
> > But "callable attributes" aren't the same thing as methods; most are
> > methods,
> > but not all. Sometimes, they're data used by the object. The fact that
> > data attributes can be callable
On 28/06/2011 12:04, Fred Drake wrote:
On Tue, Jun 28, 2011 at 6:54 AM, Michael Foord
wrote:
Added to which there are other descriptors, notably property, that are not
directly callable but are not provided as normal "data attributes" (although
the access syntax is the same). Properties are mu
On Tue, Jun 28, 2011 at 6:54 AM, Michael Foord
wrote:
> Added to which there are other descriptors, notably property, that are not
> directly callable but are not provided as normal "data attributes" (although
> the access syntax is the same). Properties are much closer to methods as
> they are im
On 28/06/2011 11:44, Fred Drake wrote:
On Tue, Jun 28, 2011 at 2:33 AM, Nick Coghlan wrote:
The two terms I've got out of this thread are "callable attributes"
(instance/static/class methods, etc) and "data attributes" (everything
else). Both seem reasonable to me, creating two largely disjoint
On Tue, Jun 28, 2011 at 2:33 AM, Nick Coghlan wrote:
> The two terms I've got out of this thread are "callable attributes"
> (instance/static/class methods, etc) and "data attributes" (everything
> else). Both seem reasonable to me, creating two largely disjoint sets
> that together cover all the
On Tue, Jun 28, 2011 at 3:05 PM, Ben Finney wrote:
> I still don't have a good term for “non-callable attribute”, though.
The two terms I've got out of this thread are "callable attributes"
(instance/static/class methods, etc) and "data attributes" (everything
else). Both seem reasonable to me, c
Eric Snow writes:
> On Mon, Jun 27, 2011 at 8:11 PM, Ben Finney
> wrote:
> > "callable attributes" describes exactly what they are, in terms that
> > will remain useful to the person learning Python.
>
> The usage of the object determines what we call it then
No, the capability of the attribut
On Mon, Jun 27, 2011 at 8:11 PM, Ben Finney wrote:
> Rob Cliffe writes:
>
>> 'function attributes' ? 'def attributes' ?
>
> -1. They don't have to be functions, and hence don't have to be created
> by 'def'.
>
>> Or just stick with method attributes' ?
>
> "callable attributes" describes exactly
Rob Cliffe writes:
> On 27/06/2011 15:08, R. David Murray wrote:
> > I guess what I'm saying is that I am more comfortable calling them
> > all attributes than calling them all members. The term 'members'
> > isn't used anywhere in the language itself, as far as I can recall,
> > whereas getattr
On Tue, Jun 28, 2011 at 8:46 AM, Michael Foord
wrote:
> So the Python 2.2 what's new talks about attributes and methods as different
> things Of course the context makes it clear, but this mirrors how I use
> the terms in discussion and how I see others generally using them.
>
> Great topic fo
R. David Murray wrote:
So, the correct generic term for something that can be accessed
via attribute notation is attribute. The more specific term for an
attribute that is a method is method. We don't currently have a more
specific collective term for attributes that aren't methods. *That*
is
On 27/06/2011 23:18, Terry Reedy wrote:
On 6/27/2011 2:33 PM, Terry Reedy wrote:
Let me repeat that that is historically wrong for Python, and illustrate
why the term 'members' should not be used. From the 1.5 Language
Reference, 3.2 Standard type hierarchy: "There are also some 'generic'
speci
On 6/27/2011 2:33 PM, Terry Reedy wrote:
Let me repeat that that is historically wrong for Python, and illustrate
why the term 'members' should not be used. From the 1.5 Language
Reference, 3.2 Standard type hierarchy: "There are also some 'generic'
special attributes, not listed with the indivi
On 6/27/2011 5:42 AM, Michael Foord wrote:
On 27/06/2011 09:24, Antoine Pitrou wrote:
FWIW, I tend to understand "members" as "methods + attributes", which
makes
it a nice term to use for that purpose.
That is my understanding / use of the terms as well.
On 6/27/2011 5:45 AM, Oleg Broytman
On Mon, 27 Jun 2011 20:30:12 +0100, Michael Foord
wrote:
> On 27/06/2011 20:22, R. David Murray wrote:
> > [snip...]
> > So, the correct generic term for something that can be accessed
> > via attribute notation is attribute. The more specific term for an
> > attribute that is a method is method
On 27/06/2011 20:22, R. David Murray wrote:
[snip...]
So, the correct generic term for something that can be accessed
via attribute notation is attribute. The more specific term for an
attribute that is a method is method. We don't currently have a more
specific collective term for attributes t
On Mon, 27 Jun 2011 19:27:26 +0200, Antoine Pitrou wrote:
> Le Tue, 28 Jun 2011 00:36:20 +1000,
> Nick Coghlan a écrit :
> > And no, the fact that methods can be treated as attributes is not a
> > minor detail. It is *fundamental* to Python's object model that
> > *methods are not a special case
On 6/27/2011 4:24 AM, Antoine Pitrou wrote:
Le Mon, 27 Jun 2011 11:32:32 +1000,
Nick Coghlan a écrit :
"Members" is a historical relic that is best replaced by "attributes"
or "data attributes" if we want to explicitly exclude methods for some
reason. "Methods" is a subset of attributes that
Le Tue, 28 Jun 2011 00:36:20 +1000,
Nick Coghlan a écrit :
> And no, the fact that methods can be treated as attributes is not a
> minor detail. It is *fundamental* to Python's object model that
> *methods are not a special case of attribute access*.
Uh, and so what?
Again, the stdlib docs are d
Egads.
Back when I wrote
"Members and methods" should just be "attributes".
I used quotes to specifically indicate that this applied to the phrase
"members and methods", not their separate use. I guess I wasn't obvious
enough.
The general & Python-historical uses of "members" is unfortunat
On Mon, 27 Jun 2011 15:27:12 +0100, Michael Foord
wrote:
> On 27/06/2011 15:08, R. David Murray wrote:
> > 'data attributes' can so easily become something else in Python...it
> > seems to me that the only real difference between 'data attributes' and
> > 'method attributes' in Python is that the
Nick Coghlan wrote:
> And no, the fact that methods can be treated as attributes is not a
> minor detail. It is *fundamental* to Python's object model that
> *methods are not a special case of attribute access*. All attributes
> work the same way, it is just the way functions implement the
> desc
Nick Coghlan writes:
> And no, the fact that methods can be treated as attributes is not a
> minor detail. It is *fundamental* to Python's object model that
> *methods are not a special case of attribute access*.
That's ambiguous. I assume you mean "just a case of attribute access,
and not sp
On Tue, Jun 28, 2011 at 12:27 AM, Michael Foord
wrote:
> Well perhaps, but where does the language draw the distinction between
> attributes and "data attributes" as you all them (a term entirely new to
> me)? Only in the descriptor protocol and that term isn't used there
> (data-descriptors and n
On Tue, Jun 28, 2011 at 12:08 AM, R. David Murray wrote:
> While I agree that using 'attribute' when only methods are being discussed
> would most likely be confusing, and that it can be tricky to clearly
> word things when both are being discussed, the existence in the language
> of getattr, seta
On 27/06/2011 15:08, R. David Murray wrote:
On Mon, 27 Jun 2011 09:47:05 +0100, Paul Moore wrote:
On 27 June 2011 09:24, Antoine Pitrou wrote:
While I know it is technically right, I find it a bit strange to refer to
methods as "attributes". We're describing an API, not the inner working of
t
On 27/06/2011 15:08, R. David Murray wrote:
Wow, all these people who like 'members', and I can't think of ever
using that term in a Python context.
While I agree that using 'attribute' when only methods are being discussed
would most likely be confusing, and that it can be tricky to clearly
wor
On Mon, 27 Jun 2011 09:47:05 +0100, Paul Moore wrote:
> On 27 June 2011 09:24, Antoine Pitrou wrote:
> > While I know it is technically right, I find it a bit strange to refer to
> > methods as "attributes". We're describing an API, not the inner working of
> > the object model. Also, people just
On Mon, Jun 27, 2011 at 10:24:28AM +0200, Antoine Pitrou wrote:
> FWIW, I tend to understand "members" as "methods + attributes", which makes
> it a nice term to use for that purpose.
That's my feeling too.
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
On 27/06/2011 09:24, Antoine Pitrou wrote:
Le Mon, 27 Jun 2011 11:32:32 +1000,
Nick Coghlan a écrit :
On Mon, Jun 27, 2011 at 7:52 AM, Terry Reedy wrote:
or the 'attribute' substitution everywhere makes sense?
No.
My strong history-based opinions ;-).
+1 to what Terry said.
"Members" is
On 27 June 2011 09:24, Antoine Pitrou wrote:
> While I know it is technically right, I find it a bit strange to refer to
> methods as "attributes". We're describing an API, not the inner working of
> the object model. Also, people just discovering Python will probably be a
> bit surprised if we st
Le Mon, 27 Jun 2011 11:32:32 +1000,
Nick Coghlan a écrit :
> On Mon, Jun 27, 2011 at 7:52 AM, Terry Reedy wrote:
> >> or the 'attribute' substitution everywhere makes sense?
> >
> > No.
> >
> > My strong history-based opinions ;-).
>
> +1 to what Terry said.
>
> "Members" is a historical relic
On Mon, Jun 27, 2011 at 7:52 AM, Terry Reedy wrote:
>> or the 'attribute' substitution everywhere makes sense?
>
> No.
>
> My strong history-based opinions ;-).
+1 to what Terry said.
"Members" is a historical relic that is best replaced by "attributes"
or "data attributes" if we want to explici
On 6/26/2011 2:52 PM, Senthil Kumaran wrote:
http://bugs.python.org/issue10403 is a documentation bug which talks
about using the term 'attribute' instead of the term 'member' when it
denotes the class attributes. Agreed.
But the discussion goes on to mention that,
"Members and methods" should
Hello!
http://bugs.python.org/issue10403 is a documentation bug which talks
about using the term 'attribute' instead of the term 'member' when it
denotes the class attributes. Agreed.
But the discussion goes on to mention that,
"Members and methods" should just be "attributes".
I find this bit
52 matches
Mail list logo
