views:

378

answers:

5

In Python properties are used instead of the Java-style getters, setters. So one rarely sees get... or set.. methods in the public interfaces of classes.

But in cases were a property is not appropriate one might still end up with methods that behave like getters or setters. Now my questions: Should these method names start with get_ / set_? Or is this unpythonic vebosity since it is often obvious what is meant (and one can still use the docstring to clarify non-obvious situations)?

This might be a matter of personal taste, but I would be interested in what the majority thinks about this? What would you prefer as an API user?

Example: Say we have an object representing multiple cities. One might have a method get_city_by_postalcode(postalcode) or one could use the shorter name city_by_postalcode. I tend towards the later.

+2  A: 

I think shorter is better, so I tend to prefer the later. But what's important is to consistant with your project: don't mix the two methods. If you jump into someone else's project, keep what the other developers choosed initially.

Oli
+1  A: 

I've seen it done both ways. Coming from an Objective-C background, I usually do foo()/set_foo() if I can't use a property (although I try to use properties whenever possible). It doesn't really matter that much, though, as long as you're consistent.

(Of course, in your example, I wouldn't call the method get_city_by_postalcode() at all; I'd probably go with translate_postalcode or something similar that uses a better action verb in the name.)

mipadi
Actually, I think "get_city_by_postalcode" is more descriptive than "translate_postalcode".
Jeremy Cantrell
+2  A: 

You won't ever loose the chance to make your property behave like a getter/setter later by using descriptors. If you want to change a property to be read only you can also replace it with a getter method with the same name as the property and decorate it with @property. So my advice is to avoid getters/setters unless the project you are working on already uses them, because you can always change your mind later and make properties read-only, write-only or whatever without modifying the interface to your class.

Vasil
+1  A: 

If it's usable as a property (one value to get or set, and no other parameters, I usually do:

class Foo(object):

    def _get_x(self):
        pass

    def _set_x(self, value):
        pass

    x = property(_get_x, _set_x)

If the getter/setter is any more complex than that, I would use get_x and set_x:

Jeremy Cantrell
A: 

If I have to use a getter/setter, I like it this way:

Suppose you have a variable self._x. Then x() would return the value of self._x, and setX(x) would set the value of self._x

Chris Cameron