This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: getattr(object,name) accepts only strings
Type: enhancement Stage:
Components: None Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: arigo, complex
Priority: normal Keywords:

Created on 2004-07-04 23:21 by complex, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg54188 - (view) Author: Viktor Ferenczi (complex) Date: 2004-07-04 23:21
getattr(object,name) function accepts only strings. This behavior prohibits some interesting usage of callables as names in database column and field references.

For example:

Someone references a database field:
value=record.field_name

Programmatically, when name is the name of the field:
value=getattr(record,field_name)

Calculated fields could be implemented by passing a callable as a field name:

def fn(record): return '%s (%s)'%(record.name,record.number)

value=getattr(record,fn)

The database backend checks if the name is callable and then call the name with the record.

But this cannot be implemented in the simple way if getattr checks if the name is a string or not. This is an unneccessary check in getattr, setattr and delattr, since prevents interesting solutions.

Temporary workaround:

value=record.__getattr__(fn)

There can be many unneccessary type checks and limitations in core and library functions. They should be removed to allow free usage.
msg54189 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2004-12-23 22:55
Logged In: YES 
user_id=4771

This is in part due to historical reasons.  I guess you know 
about "property"?  This is exactly what database people 
usually call calculated fields.
msg54190 - (view) Author: Viktor Ferenczi (complex) Date: 2005-01-02 00:29
Logged In: YES 
user_id=142612

Thanks for your comment. I know about property, of course. I
had to change an old application where reimplementing
everything with properties could be dificult. The problem
has been solved for now. I use SQLObject (www.sqlobject.org)
for new applications, whereever possible. Usage of other
Object-Relational mappings (or even ZODB) are under
consideration. - Viktor
History
Date User Action Args
2022-04-11 14:56:05adminsetgithub: 40508
2008-01-05 18:31:08christian.heimessetstatus: open -> closed
resolution: wont fix
2004-07-04 23:21:46complexcreate