views:

212

answers:

6

Using get/set seems to be a common practice in Java (for various reasons), but I hardly see Python code that uses this.

Why do you use or avoid get/set methods in Python?

+11  A: 

Cool link: Python is not Java :)

In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters.

mgv
plus setters/getters add performance cost, especially in Python.
Nick D
This *does* place an added burden on the class designer, in that instance variables implicitly become part of the class's public API. When laying out a class, explicitly think about which instance variables you want to be accessed externally vs those which are really just part of your class implementation. Prefix the internal implementation ones with a leading '_'. This is the Python warning sign that if the implementation changes, this variable might change too or even completely go away. Otherwise you'll find implementation knowledge leaking out of your class, making it hard to change later.
Paul McGuire
@Nick D: I don't think accessors are the right place to do speed optimizations in Python.
wRAR
@wRAR, probably with the new setters/getters built-in support that's true. But in general, function calls are costly in Python.
Nick D
@Nick D: I mean, that's an interpreted language which encourages readability, not performance, so there will be a lot better places for optimizations in a program.
wRAR
@wRAR, sure, I agree with that ;-)
Nick D
@Paul: If the "public" instance attribute changes, isn't that nearly always the the same as changing "public" getters and setters? Design can be fragile, but I don't see a difference between attributes/properties and getters/setters in this respect.
Roger Pate
@Roger: my point was that the designer of a library class may not realize that *every* internal attribute of a public class is visible to the outside world, and that an attribute that he/she thought was just used internally, if not named appropriately, is fair game for users of his module to access and become dependent upon. A well-intentioned effort to do some internal naming cleanup may in fact break external code, making for unexpected compatibility and upgrade problems. If an attribute is exposed as a property, it is less likely that the developer will unwittingly change the property name.
Paul McGuire
@Paul: It's *not* an internal attribute unless it's named with one or two leading underscores (with the first form generally preferred as the latter does Python's unusual name mangling). If you don't want to write docs and this issue bothers you, simply use _name by default for all instance attributes.
Roger Pate
@Roger: isn't that what I said in my original comment? Are we arguing? If so, what about?
Paul McGuire
@Paul: I don't think we're arguing, I just don't see how "this does place an added burden on the class designer" is true.
Roger Pate
@Roger: I guess I was referring to the added burden of "using _name by default for all instance attributes." Maybe I just don't think in leading underscores.
Paul McGuire
@Paul: I read it as the opposite (that not using getters/setters added a burden), but I realize it can be hard to decipher what you meant six months later.
Roger Pate
+7  A: 

No, it's unpythonic. The generally accepted way is to use normal data attribute and replace the ones that need more complex get/set logic with properties.

Max Shawabkeh
+1: "We're all adults here". The code is visible. "private" and "getter/setter" don't create any value when all the code can be seen.
S.Lott
+6  A: 

Here is what Guido van Rossum says about that in Masterminds of Programming

What do you mean by "fighting the language"?

Guido: That usually means that they're trying to continue their habits that worked well with a different language.

[...] People will turn everything into a class, and turn every access into an accessor method,
where that is really not a wise thing to do in Python; you'll have more verbose code that is
harder to debug and runs a lot slower. You know the expression "You can write FORTRAN in any language?" You can write Java in any language, too.

Nick D
+3  A: 

Your observation is correct. This is not a normal style of Python programming. Attributes are all public, so you just access (get, set, delete) them as you would with attributes of any object that has them (not just classes or instances). It's easy to tell when Java programmers learn Python because their Python code looks like Java using Python syntax!

I definitely agree with all previous posters, especially @Maximiliano's link to Phillip's famous article and @Max's suggestion that anything more complex than the standard way of setting (and getting) class and instance attributes is to use Properties (or Descriptors to generalize even more) to customize the getting and setting of attributes! (This includes being able to add your own customized versions of private, protected, friend, or whatever policy you want if you desire something other than public.)

As an interesting demo, in Core Python Programming (chapter 13, section 13.16), I came up with an example of using descriptors to store attributes to disk instead of in memory!! Yes, it's an odd form of persistent storage, but it does show you an example of what is possible!

Here's another related post that you may find useful as well: http://stackoverflow.com/questions/2123585/python-multiple-properties-one-setter-getter

wescpy
+5  A: 

In python, you can just access the attribute directly because it is public:

class MyClass(object):

    def __init__(self):
        self.my_attribute = 0  

my_object = MyClass()
my_object.my_attribute = 1 # etc.

If you want to do something on access or mutation of the attribute, you can use properties:

class MyClass(object):

    def __init__(self):
        self._my_attribute = 0

    @property
    def my_attribute(self):
        # Do something if you want
        return self._my_attribute

    @my_attribute.setter
    def my_attribute(self, value):
        # Do something if you want
        self._my_attribute = value

Crucially, the client code remains the same.

blokeley
+3  A: 

The short answer to your question is no, you should use properties when needed. Ryan Tamyoko provides the long answer in his article Getters/Setters/Fuxors

The basic value to take away from all this is that you want to strive to make sure every single line of code has some value or meaning to the programmer. Programming languages are for humans, not machines. If you have code that looks like it doesn’t do anything useful, is hard to read, or seems tedious, then chances are good that Python has some language feature that will let you remove it.

Shane C. Mason