Inheriting automatic attributes initializer considered harmful?

[Thomas Wittek]

Hi!

I'm relatively new to Python, so maybe there is an obvious answer to my
question, that I just didn't find, yet.

I've got quite some classes (from a data model mapped with SQL-Alchemy)
that can be instatiated using kwargs for the attribute values. Example:

class User(object):
def __init__(self, name=None):
self.name = name

u = User(name="user name")

Writing such constructors for all classes is very tedious.
So I subclass them from this base class to avoid writing these constructors:

class AutoInitAttributes(object):
def __init__(self, **kwargs):
for k, v in kwargs.items():
getattr(self, k) # assure that the attribute exits
setattr(self, k, v)

Is there already a standard lib class doing (something like) this?
Or is it even harmful to do this?
Although I cannot see any problems with it, I feel very unsafe about
that, because I've not seen this (in the few lines from some tutorials)
before.

Regards
--
Thomas Wittek
Web: http://gedankenkonstrukt.de/
Jabber: st*********@jabber.i-pobox.net
GPG: 0xF534E231

[Andrew Durdin]

On 10/17/07, Thomas Wittek <ma**@gedankenkonstrukt.dewrote:

>
Writing such constructors for all classes is very tedious.
So I subclass them from this base class to avoid writing these constructors:

class AutoInitAttributes(object):
def __init__(self, **kwargs):
for k, v in kwargs.items():
getattr(self, k) # assure that the attribute exits
setattr(self, k, v)

Is there already a standard lib class doing (something like) this?
Or is it even harmful to do this?

It depends on your kwargs and where they're coming from. You could do
something like this, for example:

def fake_str(self):
return "not a User"

u = User(__str__=fake_str)
str(u)
Does SQLAlchemy let you get a list of column names? If so you could do:

class AutoInitAttributes(object):
def __init__(self, **kwargs):
valid_attrs = set(get_column_names_from_sqlalchemy())
# Only set valid attributes, ignoring any other kwargs
for k in set(kwargs.keys()) & valid_attrs:
setattr(self, k, kwargs[k])

Andrew

[Thomas Wittek]

Andrew Durdin:

>Is there already a standard lib class doing (something like) this?
Or is it even harmful to do this?

It depends on your kwargs and where they're coming from.

They should come from my own code.

Does SQLAlchemy let you get a list of column names?

Generellay, it does.
But it also generates some additional attributes dynamically that are
not directly defined as columns.
So, restricting the attributes to the columns would be too strict.

Thanks!
--
Thomas Wittek
Web: http://gedankenkonstrukt.de/
Jabber: st*********@jabber.i-pobox.net
GPG: 0xF534E231

[Alex Martelli]

Andrew Durdin <ad*****@gmail.comwrote:

On 10/17/07, Thomas Wittek <ma**@gedankenkonstrukt.dewrote:

Writing such constructors for all classes is very tedious.
So I subclass them from this base class to avoid writing these constructors:

class AutoInitAttributes(object):
def __init__(self, **kwargs):
for k, v in kwargs.items():
getattr(self, k) # assure that the attribute exits
setattr(self, k, v)

Is there already a standard lib class doing (something like) this?
Or is it even harmful to do this?

It depends on your kwargs and where they're coming from. You could do
something like this, for example:

def fake_str(self):
return "not a User"

u = User(__str__=fake_str)
str(u)

....and, if you did, that would be totally harmless (in a new-style class
as shown by the OP):

>>class AutoInitAttributes(object):

.... def __init__(self, **kwargs):
.... for k, v in kwargs.items():
.... getattr(self, k) # assure that the attribute exits
.... setattr(self, k, v)
....

>>class User(AutoInitAttributes): pass

....

>>def fake_str(self):

.... return "not a User"
....

>>u = User(__str__=fake_str)
str(u)

'<__main__.User object at 0x635f0>'

>>>

fake_str is not called, because special-method lookup occurs on the
TYPE, *NOT* on the instance.

The OP's idea is handy for some "generic containers" (I published it as
the "Bunch" class back in 2001 in
<http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52308>, and I
doubt it was original even then); it's not particularly recommended for
classes that need to have some specific *NON*-special methods, because
then the "overwriting" issue MIGHT possibly be a (minor) annoyance.
Alex

[Andrew Durdin]

On 10/17/07, Alex Martelli <al***@mac.comwrote:

>
fake_str is not called, because special-method lookup occurs on the
TYPE, *NOT* on the instance.

So it does; I'd forgotten that. I need to remember to actually check
that the code does what I think it does before posting it on c.l.p
:-|

Andrew