object.attribute vs. object.getAttribute()

[Roy Smith]

For the past 6-8 months, I've spent most of my time writing C++ and a
little bit of Java. Both of these languages support and encourage the
use of private data and explicit accessor functions, i.e. instead of
writing x = foo.bar, you write x = foo.getBar(). Now that I'm back to
writing Python, I find myself in a quandry.

Historically, I've always avoided accessor functions and just reached
directly into objects to get the value of their attributes. Since
Python doesn't have private data, there really isn't much advantage to
writing accessors, but somehow I'm now finding that it just feels wrong
not to. I'm not sure if this feeling is just a C++/Java-ism that will
cure itself with time, or if perhaps it really does make sense and I
should change the way I code.

On the plus side, accessors/mutators give me:

1) Implicit documentation of which attributes I intended to be part of
an object's externally visible state (accessors).
2) Hooks to do data checking or invarient assertions (mutators).
3) Decoupling classes by hiding the details of data structures.
4) Vague feeling that I'm doing a good thing by being more in line with
mainstream OO practices

On the minus side:

1) More typing (which implies more reading, which I think reduces the
readability of the finished product).
2) Need to write (and test) all those silly little functions.
3) Performance hit due to function call overhead.
4) Only the appearance of private data (modulo some slots hackery).
5) Code is harder to change (adding functionality means going back and
adding more slots).
6) Vague feeling that I'm dirtying myself by letting C++ and Java change
my Python coding habits

Comments?

 

[Jeff Epler]

For the past 6-8 months, I've spent most of my time writing C++ and a
little bit of Java. Both of these languages support and encourage the
use of private data and explicit accessor functions, i.e. instead of
writing x = foo.bar, you write x = foo.getBar(). Now that I'm back to
writing Python, I find myself in a quandry.

Historically, I've always avoided accessor functions and just reached
directly into objects to get the value of their attributes. Since
Python doesn't have private data, there really isn't much advantage to
writing accessors, but somehow I'm now finding that it just feels wrong
not to. I'm not sure if this feeling is just a C++/Java-ism that will
cure itself with time, or if perhaps it really does make sense and I
should change the way I code.

Write your python code naturally, using 'x = foo.bar'. Derive all your
classes from 'object' (use new-style classes). If you ever need
to do something "behind the scenes", you can switch to using "property",
and have a function automatically called on attribute read, write, and
delete---and it even documents itself:

class C(object):
def __init__(self):
self._y = 0

def get_x(self):
return self._y * self._y

def set_x(self, val):
self._y = val

def del_x(self):
raise TypeError, "Cannot delete attribute"

x = property(get_x, set_x, del_x,
"A stupid attribute that squares itself"
"... and won't go away")
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/tmp/roy.py", line 12, in del_x
raise TypeError, "Cannot delete attribute"
TypeError: Cannot delete attribute[...]
| ----------------------------------------------------------------------
| Properties defined here:
|
| x
| A stupid attribute that squares itself... and won't go away
[...]

Jeff

 

[Michael Geary]

I've always disliked accessor methods in C++ and Java. I can understand the
reason for using them, but they are just so ugly.

Danger: Advice from a Python newbie follows...

My suggestion would be to use Python properties, as defined with the
property() function that was added in 2.2. Best of both worlds: You get the
clean syntax of directly reading and writing properties just as if they were
attributes, but behind the scenes you've defined get/set/del functions for
each property.

Personally, I wouldn't define properties for everything--I would use
ordinary attributes wherever they do the job. The beauty is that you can
always replace an attribute with a property without having to change the
calling code--which eliminates most of the reason for using accessor methods
as you would in C++.

-Mike

 

[Lulu of the Lotus-Eaters]

|1) Implicit documentation of which attributes I intended to be part of
|an object's externally visible state (accessors).

Some attribute names start with an underscore. Those are the ones that
are NOT intended to be part of the external interface.

|2) Hooks to do data checking or invarient assertions (mutators).

Yep, you need accessors (or properties) to do this.

|3) Decoupling classes by hiding the details of data structures.

Initial underscores again.

|4) Vague feeling that I'm doing a good thing by being more in line with
|mainstream OO practices

If you want to be mainstream, use VB. But accessors are not IMO a
requirement for "proper" OOP.

Yours, Lulu...

 

[John Roth]

For the past 6-8 months, I've spent most of my time writing C++ and a
little bit of Java. Both of these languages support and encourage the
use of private data and explicit accessor functions, i.e. instead of
writing x = foo.bar, you write x = foo.getBar(). Now that I'm back to
writing Python, I find myself in a quandry.

Historically, I've always avoided accessor functions and just reached
directly into objects to get the value of their attributes. Since
Python doesn't have private data, there really isn't much advantage to
writing accessors, but somehow I'm now finding that it just feels wrong
not to. I'm not sure if this feeling is just a C++/Java-ism that will
cure itself with time, or if perhaps it really does make sense and I
should change the way I code.

I'm with Jeff on this one. If it looks like a value, then access it
directly.
If you need to slide a mutator in under it, it's simple enough to make
it a property later without affecting any of the code that uses it.

On the plus side, accessors/mutators give me:

1) Implicit documentation of which attributes I intended to be part of
an object's externally visible state (accessors).

Use the underscore convention.

2) Hooks to do data checking or invarient assertions (mutators).
3) Decoupling classes by hiding the details of data structures.
4) Vague feeling that I'm doing a good thing by being more in line with
mainstream OO practices

4 is actually the same thing as 3, except not stated as cleanly.

On the minus side:

1) More typing (which implies more reading, which I think reduces the
readability of the finished product).
2) Need to write (and test) all those silly little functions.
3) Performance hit due to function call overhead.
4) Only the appearance of private data (modulo some slots hackery).
5) Code is harder to change (adding functionality means going back and
adding more slots).
6) Vague feeling that I'm dirtying myself by letting C++ and Java change
my Python coding habits

Items 1 through 3 don't matter if you use properties. You use them when
you need them, otherwise you simply access the attribute directly.

If you're using Python, you don't worry about private data. Use the
underscore convention, and don't worry otherwise.

Don't use slots.

I never worry about where a good idea comes from.

John Roth

 

[Troy Melhase]

Hi Roy:

I'm not sure if this feeling is just a C++/Java-ism that will
cure itself with time, or if perhaps it really does make sense and I
should change the way I code.

If you're not sure, I suggest you err on the side of caution. To me caution
means writting less code, not more. And this isn't really an either-or
proposition. One of the best things about properties is that clients can't
easily distinguish them from normal attribute access. Nothing stops you
from starting with simple attributes and then later changing them to
properties later.

6) Vague feeling that I'm dirtying myself by letting C++ and Java change
my Python coding habits

This need not be vague. I have that feeling concretely when thinking of
Java.

-troy

 

[Aurelio Martin Massoni]

Read this nice article "Why getter and setter methods are evil: Make
your code more maintainable by avoiding accessors"

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

 

[Sean Ross]

Hi.

[snip]

1) More typing (which implies more reading, which I think reduces the
readability of the finished product).
2) Need to write (and test) all those silly little functions.

If you only intend to create simple properties[*], then the following recipe
may address issues 1) and 2) (except for the testing part):

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/157768

If you're going to create more complex properties, you may find this
recipe(idiom) of interest:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/205183


Hope that's useful,
Sean



[*] By "simple properties", I mean something like the following:

''' assume we're inside a class definition
and self.__foo has been initialized.
'''
def get_foo(self):
return self.__foo
def set_foo(self, value):
self.__foo = value
def del_foo(self):
del self.__foo
foo = property(fget=get_foo, fset=set_foo, fdel=del_foo, doc="foo")

 

[Michael Geary]

Read this nice article "Why getter and setter methods are evil: Make
your code more maintainable by avoiding accessors"

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

That's an interesting article. Be sure to read the comments at the end of
page 3--the real fun starts there!

-Mike