UncleZeiv's Corner » getters http://unclezeiv.kerid.org still in love with underscores Sun, 15 Jan 2012 22:30:35 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 About getters and setters in Python http://unclezeiv.kerid.org/2009/08/about-getters-and-setters-in-python?utm_source=rss&utm_medium=rss&utm_campaign=about-getters-and-setters-in-python http://unclezeiv.kerid.org/2009/08/about-getters-and-setters-in-python#comments Tue, 25 Aug 2009 18:43:34 +0000 UncleZeiv http://unclezeiv.kerid.org/?p=91 Recently I’ve been developing a fairly large Python application, involving a somewhat articulate and deep class hierarchy. With time, I ended up writing a certain amount of getters and setters which felt suspiciously unpythonic. Looking for better solutions I stumbled upon a number of sources making fun of people writing getters and setters in Python (e.g. Python Is Not Java), because:

  • there’s no real data member protection in Python anyway (“we are all consenting adults here”)
  • if you later want to embed some logic in the retrieval of an attribute, you can keep the same interface by just adding a property

These arguments were so compelling that made me feel pretty stupid. Consequently, I immediately started converting all my getters and setters into variables or, when needed, into properties.

Unfortunately, it soon became apparent that I had not considered all the facets of the problem. Problems surfaced soon, primarily because, as I had to find out the hard way, avoiding getters/setters does not play that well with inheritance.

First of all, overriding the access of an attribute becomes a bit quirky — despite being perfectly acceptable when using getters. In particular, the child class must know if a certain attribute is indeed an attribute or a property — and this already breaks the promise of keeping the switch from variable to property a local change.

1
2
3
4
5
6
7
8
9
10
11
12
class Foo(object):
    @property
    def foo(self):
        return 5

class Bar(Foo):
    @property
    def foo(self):
        return Foo.foo.fget(self) + 1

print Foo().foo # 5
print Bar().foo # 6

The syntax gets really cumbersome. For instance, if you want to override only the getter or the setter, verbosity ensues:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
class Foo(object):
    @property
    def foo(self):
        return 5

    @foo.setter
    def foo(self, val):
        print val

# one way to do that
class Bar1(Foo):
    @property
    def foo(self):
        return Foo.foo.fget(self) + 1

    @foo.setter
    def foo(self, val):
        return Foo.foo.fset(self, val)

# another way
class Bar2(Foo):
    def foo_get(self):
        return Foo.foo.fget(self) + 1

    def foo_set(self, val):
        return Foo.foo.fset(self, val)

    foo = property(foo_get, foo_set)

Foo().foo = 4
Bar1().foo = 3
Bar2().foo = 2

Granted, true Pythoners would say that this is not Python’s fault but mine, as I have evidently made some wrong, or at least unpythonic, design decisions at a higher level. That’s an acceptable criticism, but I still think that the organization of my program was fair when employing getters and setters. Most importantly, though, the consequences of substituting them in class hierarchies where overriding is common have not been sufficiently explained by the previously mentioned Internet sources.

In other words, sometimes “practicality beats purity“!

]]> http://unclezeiv.kerid.org/2009/08/about-getters-and-setters-in-python/feed 6