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 AutoInitAttribu tes(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*********@jab ber.i-pobox.net
GPG: 0xF534E231

[Andrew Durdin]

On 10/17/07, Thomas Wittek <ma**@gedankenk onstrukt.dewrot e:

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

class AutoInitAttribu tes(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__=fa ke_str)
str(u)
Does SQLAlchemy let you get a list of column names? If so you could do:

class AutoInitAttribu tes(object):
def __init__(self, **kwargs):
valid_attrs = set(get_column_ names_from_sqla lchemy())
# 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*********@jab ber.i-pobox.net
GPG: 0xF534E231

[Alex Martelli]

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

On 10/17/07, Thomas Wittek <ma**@gedankenk onstrukt.dewrot e:

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

class AutoInitAttribu tes(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__=fa ke_str)
str(u)

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

>>class AutoInitAttribu tes(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(AutoInitAt tributes): pass

....

>>def fake_str(self):

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

>>u = User(__str__=fa ke_str)
str(u)

'<__main__.Use r 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.activestat e.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 "overwritin g" issue MIGHT possibly be a (minor) annoyance.
Alex

[Andrew Durdin]

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

>
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