3

Suppose I have a class NamedObject which has an attribute name. Now if I had to use a setter, I would first have to define a getter (I guess?) like so:

class NamedObject: def __init__(self, name): self.name = name @property def name(self): return self._name

Now I was wondering, inside the setter, should I use self._name or self.name, the getter or the actual attribute? When setting the name, I ofc. need to use _name, but what about when I'm getting INSIDE the setter? For example:

@name.setter def name(self, value): if self._name != str(value): # Or should I do 'if self.name != value' ? self.doStuff(self._name) # Or doStuff(self.name) ? self.doMoreStuff() self._name = str(value)

Does it actually matter which one to use, and why use one over the other?

Improve this question
8
  • 1
    In Python, you usually don't use getters and setters at all. Commented Nov 18, 2012 at 19:15
  • Why not? Why do they exist then? O.o every other person I ask tells me to use them, and every other tells me not to. Commented Nov 18, 2012 at 19:20
  • 3
    @Mahi Use them when you actually have a reason to use them - e.g. you want to do something other than just directly assigning and reading the value of an attribute (e.g. validation). Commented Nov 18, 2012 at 19:21
  • You usually first just use an instance attribute, then when you believe you have to add some actions/controls for getting/setting you change it to a property, in this way you improve your code in a backward compatible way. Adding random getters/setters that do not do anything is only writing more code, without providing any kind of information hiding or feature. Commented Nov 18, 2012 at 19:25
  • 1
    @Amber Yeah sorry that was a bad example I came up with there (the main post), but in my actual code I have like 15 lines of code on the setter, and only one on the getter. Should I use getter and setter or not? Commented Nov 18, 2012 at 19:29

4 Answers 4

Reset to default
3

There's no normal reason to use the external interface when your setter is part of the internal interface. I suppose you might be able to construct a scenario where you might want to, but by default, just use the internal variable.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

If your getter has significant logic (like lazy initialization), then you should access through the getter all the time.

class Something(object): UNINITIALIZED = object() LAZY_ATTRS = ('x','y','z') def __init__(self): for attr in self.LAZY_ATTRS: setattr(self, '_'+attr, self.UNINITIALIZED) def _get_x(self): if self._x is self.UNINITIALIZED: self._x = self.doExpensiveInitStuff('x') return self._x

But if all your getter does is return self._x, just access the internal variable directly.

Improve this answer

Comments

1

Using the getter instead of just accessing the internal variable adds another function call to your setting logic, and in Python, function calls are expensive. If you are writing this:

def _get_x(self): return self._x def _set_x(self, value): self._x = value x = property(fget=_get_x, fset=_set_x)

then you are suffering from "Too Much Java" syndrome. Java developers have to write this kind of stuff, because if it later becomes necessary to add behavior to the setting or getting of x, all the accesses to x outside of the class have to be recompiled. But in Python, you are far better off keeping things simple, and just defining x as an instance variable, and converting to a property only when the need arises to add some kind of setting or getting behavior. See YAGNI and YAGNI.

Improve this answer

2 Comments

Read my second comment on the main post. I come from C++ side, not Java, but I guess they're pretty much the same. I actually have like 15 lines of code in my setter, I just wrote a quick example for the sake of the question. So this again didn't answer my actual question, but I guess I should blame myself for giving a bad example code :P
What you have gotten from your simple example is The Conventional Wisdom on using properties in Python: "Don't do it until you need to." If all your getter is doing is return self._name, then just access self._name in your setter, and avoid an unnecessary function call. If you later need to add behavior to the getter as well and if this behavior is significant from within the setter, you are probably close enough to the setter code to track down the offending direct references to self._name.
0

Paul already answered well.

For the sake of completeness I'd like to add that using getters/setters consistently makes it easier to override a class. There are several implications here.

If you envision that a particular class is very likely to be overriden/extended by yourself or others, then using getters/setters early on might be beneficial in terms of less time spent later for refactoring. Still, I agree to the keep it simple viewpoint: Use the below only sparingly, because of the runtime cost and reading/coding effort.

If validation is done in the getter, too, then either use the instance attribute directly in the setter, or provide two different getters name() and _name() (or name_already_checked()) so that both can be overridden and use the simple getter without validation inside the setter. This is to allow extension of both the fast, no-validation type of getter as well as the usual, provided for customers, getter.

This does violate the YAGNI principle that Paul pointed to. However, if you do release code for a wider audience "overengineering" is often advisable. Libraries benefit from added flexibility and foresight.

Improve this answer

Comments