471,353 Members | 1,794 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,353 software developers and data experts.

Inheriting automatic attributes initializer considered harmful?

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
Oct 17 '07 #1
4 1161
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
Oct 17 '07 #2
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
Oct 17 '07 #3
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
Oct 17 '07 #4
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
Oct 18 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Rasmus Fogh | last post: by
9 posts views Thread by mike420 | last post: by
29 posts views Thread by shaun roe | last post: by
4 posts views Thread by Pete Forman | last post: by
reply views Thread by Terry Hancock | last post: by
5 posts views Thread by Wu | last post: by
16 posts views Thread by Niels L Ellegaard | last post: by
2 posts views Thread by dj3vande | last post: by
4 posts views Thread by AalaarDB | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.