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

Michael Foord fuzzyman at voidspace.org.uk
Tue Jun 28 13:35:40 CEST 2011

On 28/06/2011 12:04, Fred Drake wrote:
> On Tue, Jun 28, 2011 at 6:54 AM, Michael Foord
> <fuzzyman at voidspace.org.uk>  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 implemented on the class and fetched via the descriptor protocol.
>> Instead of "data attributes" I prefer the term "instance attributes"
>> although that doesn't include "class attributes" (or more precisely it
>> doesn't cover "class attributes that aren't descriptors").
> Given the availability of __getattr__ and __getattribute__, I consider
> properties an implementation detail for some attributes.  The fact that
> Python code is called on access is only marginally interesting.

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 uninteresting detail.

__getattr__ and __getattribute__ are interesting - they allow you to use 
attribute access syntax for things that *aren't* attributes.

I appreciate the fact that the Python data-model means methods are just 
object attributes, but they're not *instance attributes* and sometimes 
you need to make a distinction. (And yes it is helpful if the standard 
terminology leads people into a better understanding of the Python data 
model, but that still doesn't change the need on occasion for 
terminology that doesn't need to be explained whenever it is used.)

Given that how even methods are to be described depends on the context 
(if you're fetching bound methods as objects then it makes perfect sense 
to just talk about them as attributes) it doesn't seem an area amenable 
to one-size-fits-all terminology.

>> 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 used then that changes I guess. I'd still normally just use
>> "attributes" though...
> I'd read "data attributes" the same as "non-method attributes".  For readers,
> calling them "attributes" is typically sufficient.  It's rare to need to
> distinguish them from methods.

Yeah, this is all a grand bikeshed. I'm not sure I would understand 
"data attributes" unless it was clear from the context. I would wonder 
what qualifies something as "data".

It is an interesting question what terminology we should use in the 
documentation if we need to distinguish them, but I think that is still 
wandering away from the original question that was posed.

All the best,


>    -Fred


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

More information about the Python-Dev mailing list