[Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

[R. David Murray]

On Mon, 27 Jun 2011 15:27:12 +0100, Michael Foord <fuzzyman at voidspace.org.uk> 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 latter can be called and the
> > former can't.  But even that is not an accurate distinction, since a
> > 'data attribute' could, in fact, return a callable.
> >
> > 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 and setattr are evidence that the language considers
> > them all attributes.  I think we do the documentation readers a
> > disservice by obscuring that fact by using other terminology.
> 
> Well perhaps, but where does the language draw the distinction between 
> attributes and "data attributes" as you all them (a term entirely new to 

It doesn't, that's the point.  You'll note I put "data attributes"
in quotes :)

> me)? Only in the descriptor protocol and that term isn't used there 
> (data-descriptors and non data-descriptors is terminology used in the 
> documentation there).
> 
> If you're saying that data attributes isn't clear either (I couldn't 
> quite tell from your email) then how *do* we draw a distinction. We 
> could talk about instance attributes, non-descriptor class attributes 
> and descriptors, but that terminology requires a reasonably advanced 
> understanding of the Python data model.

That's why I said it could be difficult to find good wording when
discussing both methods and "other things".  Most people have a pretty
clear idea of what methods are, but the non-method stuff in Python does
not have any simple description that is also accurate.  Maybe 'non-method
attribute' is as close as we can get?

> I don't think that "all members, made up of attributes plus methods" is 
> hard to understand. That's a great benefit. The fact that you can 
> technically treat methods as attributes too is a minor detail.

Well, I would find that very hard to understand, since methods are
attributes, and as Nick said that is *fundamental* to the language,
not a minor detail.

--
R. David Murray           http://www.bitdance.com