views:

105

answers:

2

Having a background in Java, which is very verbose and strict, I find the ability to mutate Python objects as to give them with fields other than those presented to the constructor really "ugly".

Trying to accustom myself to a Pythonic way of thinking, I'm wondering how I should allow my objects to be constructed.

My instinct is to have to pass the fields at construction time, such as:

def __init__(self, foo, bar, baz=None):
    self.foo = foo
    self.bar = bar
    self.baz = baz

But that can become overly verbose and confusing with many fields to pass. To overcome this I assume the best method is to pass one dictionary to the constructor, from which the fields are extracted:

def __init__(self, field_map):
    self.foo = field_map["foo"]
    self.bar = field_map["bar"]
    self.baz = field_map["baz"] if baz in field_map else None

The other mechanism I can think of is to have the fields added elsewhere, such as:

class Blah(object):

    def __init__(self):
        pass

...

blah = Blah()
blah.foo = var1

But as that feels way too loose for me.

(I suppose the issue in my head is how I deal with interfaces in Python...)

So, to reiterate the question: How I should construct my objects in Python? Is there an accepted convention?

+6  A: 

The first you describe is very common. Some use the shorter

class Foo:
   def __init__(self, foo, bar):
       self.foo, self.bar = foo, bar

Your second approach isn't common, but a similar version is this:

class Thing:
   def __init__(self, **kwargs):
       self.something = kwargs['something']
       #..

which allows to create objects like

t = Thing(something=1)

This can be further modified to

class Thing:
   def __init__(self, **kwargs):
       self.__dict__.update(kwargs)

allowing

t = Thing(a=1, b=2, c=3)
print t.a, t.b, t.c # prints 1, 2, 3

As Debilski points out in the comments, the last method is a bit unsafe, you can add a list of accepted parameters like this:

class Thing:
    keywords = 'foo', 'bar', 'snafu', 'fnord'
    def __init__(self, **kwargs):
        for kw in self.keywords:
            setattr(self, kw, kwargs[kw])

There are many variations, there is no common standard that I am aware of.

Otto Allmendinger
Take care: If you blindly update your `self.__dict__` everyone can overwrite all of your instance methods and variables.
Debilski
@Debilski: you absolutely have a point, since it is easy to clobber existing attributes by mistake, but I'd like to note as well that in Python anyone could overwrite your methods and variables anyway, if they wanted to.
kaizer.se
Nice showcase on different methods.
Beau Martínez
@Debilski: If you use private scoping (ex: `self.__name`), then your methods and variables are hidden from outsiders and can't be modified. See docs: http://docs.python.org/reference/expressions.html#atom-identifiers and example: http://codepad.org/EPH6UZd0
pydave
+2  A: 

I’ve not seen many of your field_maps in real life. I think that would only make sense if you were to use the field_map at some other place in your code as well.

Concerning your third example: Even though you don’t need to assign to them (other than None), it is common practice to explicitly declare attributes in the __init__ method, so you’ll easily see what properties your object has.

So the following is better than simply having an empty __init__ method (you’ll also get a higher pylint score for that):

class Blah(object):
    def __init__(self):
        self.foo = None
        self.bar = None

blah = Blah()
blah.foo = var1

The problem with this approach is, that your object might be in a not well-defined state after initialisation, because you have not yet defined all of your object’s properties. This depends on your object’s logic (logic in code and in meaning) and how your object works. If it is the case however, I’d advise you not to do it this way. If your object relies on foo and bar to be meaningfully defined, you should really put them inside of your __init__ method.

If, however, the properties foo and bar are not mandatory, you’re free to define them afterwards.

If readability of the argument lists is an issue for you: Use keyword arguments.

Debilski