Feature request: String-inferred names

[Brad Harms]

On Fri, 04 Dec 2009 18:05:03 +1100, Ben Finney wrote:

> Brad Harms <fearsomedragonfly at gmail.com> writes:
> 
>> Anyway, it looks like the docs agree with you
>> (http://docs.python.org/glossary.html#term-attribute), so I'm not going
>> to argue.
> 
> That's good, because the terms are quite well established in Python
> terminology.

I'm just saying, if the official documentation defines the term 
"attribute" thusly, it would be silly of me to continue using my own made-
up term that means pretty much the same thing.

> 
>> 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__,
> 
> I don't know what you mean by “shortcuts to items”. The names are looked
> up in dictionaries; where do shortcuts play a part?
> 
> Try “instance attribute”, as distinct from “class attribute”.
> 
>> 2.) Attributes whose values are determined or assigned dynamically by
>> indirectly calling a function (like properties and instancemethods)
> 
> Yes, the term “property” seems to do what you want.

I wasn't asking what you call any object or any /kind/ of object. I was 
asking for a term (noun?) that describes the WAY the object is accessed 
as an attribute of an instance, with the connotation that the value of 
the attribute would be calculated dynamically (by calling a function) at 
the time the attribute was accessed. Note that the value does not have to 
exist in ANY __dict__ anywhere, it could, for example, be calculated by 
object.__getattribute__.

Example: 

>>> obj.attr

Without knowing what "obj" is or what "attr" is as it pertains to obj, 
but knowing that "attr" does not actually a key in obj.__dict_,_ and that 
its value has to be determined by some other means, what do you call the 
thing on the code line above? That is what I'm trying to find out. (HINT: 
Don't think about how the Python interpreter parses it or how the value 
is eventually determined. That's not relevant. Just understand that the 
value does not come directly from obj.__dict__.)

By the way, a "property" is an object of type __builtin__.property. A 
property with a reference in an attribute of a class /does/ call a 
function when you try to access that property as an attribute of the 
class's instances. However, properties are not the only objects that have 
this behavior, so calling objects that behave in this way is ambiguous. I 
think the actual, general term for such an object is "data descriptor," 
or just "descriptor." (http://docs.python.org/glossary.html#term-
descriptor)

> 
> The value of an instance method is *not* determined dynamically: its
> value is a function, and that value is no more dynamic than any other
> attribute of the instance.

That is incorrect. Indirectly accessing an instancemethod of a class 
through an instance of that class will trigger the descriptor behavior of 
the instancemethod type. This produces a new object, another 
instancemethod, that is bound to the instance through which it was 
accessed. It's a mouthful to say, but it is sufficiently accurate.

Heck, just look at this:

>>> class Foo(object):
...     def spam(self): pass
...
>>> foo = Foo()
>>> foo.spam
<bound method Foo.spam of <__main__.Foo object at 0x931c46c>>
>>> Foo.spam
<unbound method Foo.spam>
>>> foo.spam is Foo.spam
False
>>> foo.spam == Foo.spam
False
>>> Foo.spam.__get__(foo, Foo)
<bound method Foo.spam of <__main__.Foo object at 0x931c46c>>
>>> Foo.__dict__["spam"].__get__(foo, Foo)
<bound method Foo.spam of <__main__.Foo object at 0x931c46c>>
>>> Foo.__dict__["spam"].__get__(foo, Foo) is foo.spam
False
>>> Foo.__dict__["spam"].__get__(foo, Foo) == foo.spam
True

Also note the fact that Foo.spam is an _instancemethod_ object and not 
just a function, even though it was defined as "just a function" in the 
class body. That's because function objects are descriptors as well; it 
lets them produce unbound instancemethods. I'm not precisely sure how 
this works, though. I think it only happens when the metaclass of a class 
processes the functions in the class block.

> 
>> 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.
> 
> This is a “class attribute” as distinct from an “instance attribute”.
>

I know it's called that, but I was talking more about the fact of it 
being accessed through an instance of the class rather than 


> The distinction isn't often worth knowing, though, so you'll probably
> still have to explain it when you use it.

I beg to differ. For one thing, it affects descriptors.


Anyway, these metadiscussions are starting to give me headaches. Let's 
talk about something more interesting...


PS. I'm truly sorry once again for using email addresses and names 
inconsistently. I really am trying to solve the problem. I'm going to try 
accessing the list via comp.lang.python and Pan (newsreader for Gnome) 
for a while. Hopefully it will help.

-- 
Brad Harms -- http://alphaios.net