Feature request: String-inferred names

[Bruno Desthuilliers]

Brad Harms a écrit :
> On Tue, 2009-12-01 at 16:58 +0100, Bruno Desthuilliers wrote:
>> The Music Guy a écrit :
>> (snip)
>>> Lie Ryan, I think I see what you're saying about using __dict__ to add
>>> members
>> No "members" in Python - only attributes.
> 
>>> to a class, but it's not quite the same. __dict__ is only for
>>> attributes, NOT properties, methods, etc. which all come from the
>>> class of an object rather than the object's __dict__.
>> properties and methods (well, functions actually) ARE attributes... of 
>> the class object. And you can of course access the obj.__class__.__dict__
>>
>> Just for the record...
> 
> When I say "member" I am using it as a general term that describes any
> value that can be accessed (get, set, del) through an object.

These are what we call "attributes".

> If the
> object is referenced by a variable named `foo`, then by using `foo.name`
> or one of the XXXattr functions, one can access the member of `foo`
> called `name`. What's important to note, though, is that the term
> "member" does not make any assumption about how `foo.name` is
> implemented.
 >
> When I say "attribute," however, I am referring specifically to a member
> of an object where the member's name is a key in the object's __dict__,
> and the value is the one that is paired with that key.

What if the class uses slots then ?-)

Ok, just kidding. More seriously: these are named "instance attributes".

> Essentially, I just use "member" as a convenience term. I thought that
> was the convention among the community, but evidently it isn't as widely
> used as such as I thought. 

"members" is really C++ vocabulary.

> Anyway, it looks like the docs agree with you
> (http://docs.python.org/glossary.html#term-attribute),

I'd put it the other way round - I have no responsabilities wrt/ the 
usual Pythonic vocabulary !-)

> so I'm not going
> to argue. However, for the purpose of clean communication, I'd still
> like to have terms that refer specifically to:
> 
> 1.) "Regular" attributes, ie. those that are shortcuts to items in the
> directly associated object's __dict__, 

instance attributes


> 2.) Attributes whose values are determined or assigned dynamically by
> indirectly calling a function (like properties and instancemethods)

computed attributes

> 3.) Attributes that are read from an object with regular .dot syntax,
> but are actually attributes (in the sense of #1 above) of the  __dict__
> of the object's class.

class attributes.

Now things are even a bit more complex since computed attributes are 
usually handled by objects implementing the descriptor protocol 
(instance of the function or property type or any other custom 
descriptor), which are themselves class attributes. So sometimes - 
depending on the context - you may have to make clear whether you're 
talking about the descriptor object itself or the attribute as seen by 
client code.

HTH