Inheriting automatic attributes initializer considered harmful?

Discussion in 'Python' started by Thomas Wittek, Oct 17, 2007.

  1. 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: -pobox.net
    GPG: 0xF534E231
     
    Thomas Wittek, Oct 17, 2007
    #1
    1. Advertising

  2. On 10/17/07, Thomas Wittek <> wrote:
    >
    > 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
     
    Andrew Durdin, Oct 17, 2007
    #2
    1. Advertising

  3. 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: -pobox.net
    GPG: 0xF534E231
     
    Thomas Wittek, Oct 17, 2007
    #3
  4. Andrew Durdin <> wrote:

    > On 10/17/07, Thomas Wittek <> wrote:
    > >
    > > 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
     
    Alex Martelli, Oct 17, 2007
    #4
  5. On 10/17/07, Alex Martelli <> wrote:
    >
    > 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
     
    Andrew Durdin, Oct 18, 2007
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert Mischke
    Replies:
    3
    Views:
    1,538
    Tony Morris
    May 19, 2005
  2. Toby A Inkster
    Replies:
    19
    Views:
    761
  3. Andy Dingley

    XTech conference considered harmful?

    Andy Dingley, Feb 13, 2006, in forum: HTML
    Replies:
    2
    Views:
    603
    Richard Sexton
    Feb 14, 2006
  4. Replies:
    25
    Views:
    1,337
    Isaac To
    Oct 31, 2003
  5. Replies:
    9
    Views:
    543
Loading...

Share This Page