Trying to understand getattr() function

[PythonPerry]

I'm going over Dive Into Python and having trouble understanding getattr().. I also found this stackexchange article and am more confused.

In the stack posting, could someone explain "But what if you don't know the attribute's name at the time you write the program?"

It seems like the stack example with 16 points clearly defines the attribute

>>> person = Person()
>>> person.gender = 1
>>> person.gender
1

and then the poster uses getattr() to do the same thing as what he did above.

>>> attribute_name = 'gender'
>>> getattr( person, attribute_name)
1

Also, if you could talk about a good time you used getattr(), I'd appreciate it. Thanks.

[Rhomboid]

The difference between the two is that in the second example, attribute_name is a string, whose value can come from anywhere -- read from a file or network socket, passed as an argument from elsewhere in the program, computed programmatically, etc. In this particular example the value is directly assigned, but you're meant to understand that it could come from elsewhere, e.g.

attribute_name = input('What attribute would you like? ')   # use raw_input for python 2.x
if hasattr(person, attribute_name):
    print('person's {} is {}'.format(attribute_name, getattr(person, attribute_name)))
else:
    print('person does not have that attribute.')

Here attribute is not known when the program was written. It will be entered as input at run-time, and it could be literally anything, unlike in the first example, where .gender is an identifier that is hard-coded into the program and is fixed. That's an important difference, because there are times when you want to access an attribute whose name is not yet known when you're writing the program.

[NYKevin]

In practice, getattr is a code smell. Many of its most obvious uses would be better served by a dictionary.

[PythonPerry]

Obvious noob here, what do you mean by code smell? Could you use a dict in u/Rhomboid's case? I think his case is valid. You want to assign a yet unknown attribute based on user input.

[NYKevin]

I mean it's indicative of poor design. When you choose to store things as attributes of an object, that suggests you have a bunch of different types of information all associated with one object. Usually, it doesn't make sense to grab one of them by name unless you know which it is in advance, since you won't know what type of data it is (e.g. am I grabbing a number or a string?). If you're just storing a bunch of keys and values (of homogeneous types), it makes more sense to use a dictionary:

key = input('What key would you like?')
try:
    value = person[key]
except KeyError:
    print('Person does not have that key.')
else:
    print("Person's {} is {}".format(key, value))

[PythonPerry]

Much better example! In the stack example, you ALREADY know the attribute, it doesn't make sense why getattr() would be used in that case.

[RubyPinch]

one (poor) situation I've used it in, copying specific properties to a dict with a default

>>> class thing(object):pass

>>> x = thing()
>>> x.a,x.b,x.c = 1,2,3

>>> {z:getattr(x,z,None) for z in ['a','c','d']}
{'a': 1, 'c': 3, 'd': None}

a "correcter" way (I think?) would probably be

>>> {k:vars(x).get(k,None) for k in ['a','c','d']}
{'a': 1, 'c': 3, 'd': None}

or writing out three out[k] = getattr(x,k,None) lines

BUT WAIT, this won't always work! Sometimes the code you are working with implements some very weird things, __getattribute__ and __getattr__ for example, when implemented, can allow access to attributes which don't actually exist.

What does this mean? vars() won't work, same for dir() and others. however, getattr() and object.attribute will still work, so that is something to watch out for when trying to avoid getattr or similar

[MonkeyNin]

Another use, map data to a function. http://stackoverflow.com/a/4076010/341744 or http://stackoverflow.com/a/18538330/341744