getters and setters

[Skaperen]

the "Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015" that has been linked to a few times around here talks about "getters and setters" and suggests they are not pythonic.  can someone verify this and tell me what to have instead, with real code examples?

[micseydel]

They're unnecessary because of properties. Just extra code. Python is supposed to be lean. (You can Google "python properties" for "real code examples.")

[Mekire]

To add, even properties should only really be used when the getter/setter needs to do actual work. You don't need to (and shouldn't) use them just because you think you need getters/setters.

For example if you have a rect class and want to be able to set/get a "center" property. The set/get functions would alter the actual object attributes appropriately.

This tut I did goes into that a bit (and descriptors):
https://python-forum.io/Thread-Classes-a...escriptors

[Skaperen]

To add, even properties should only really be used when the getter/setter needs to do actual work.  You don't need to (and shouldn't) use them just because you think you need getters/setters.

For example if you have a rect class and want to be able to set/get a "center" property.  The set/get functions would alter the actual object attributes appropriately.

This tut I did goes into that a bit (and descriptors):
https://python-forum.io/Thread-Classes-a...escriptors

what if ... the original non-pythonic implementation worked like this?

thing.set_geometry( height=51, width=184 )

how would i make a more pythonic implementation of the API the doesn't require client code changes?

[Ofnuts]

To add, even properties should only really be used when the getter/setter needs to do actual work.  You don't need to (and shouldn't) use them just because you think you need getters/setters.

For example if you have a rect class and want to be able to set/get a "center" property.  The set/get functions would alter the actual object attributes appropriately.

This tut I did goes into that a bit (and descriptors):
https://python-forum.io/Thread-Classes-a...escriptors

what if ... the original non-pythonic implementation worked like this?

thing.set_geometry( height=51, width=184 )

how would i make a more pythonic implementation of the API the doesn't require client code changes?

This is not a setter, this is only a method called set-something. Setters deal with a single attribute (which is why they are heinous).

[Skaperen]

my new class has set_opts() and get_opts().  set_opts() works from named options.  get_opts() returns a dict with the options.  an additional feature: set_opts() returns a dict of unrecognized options.  this new class has 8 options (there are not setters or getters for individual options because of so many).

[Ofnuts]

my new class has set_opts() and get_opts().  set_opts() works from named options.  get_opts() returns a dict with the options.  an additional feature: set_opts() returns a dict of unrecognized options.  this new class has 8 options (there are not setters or getters for individual options because of so many).

The problem with getters/setters is not code verbosity. It is that they allow inconsistent states. If you rename some "Marmaduke Skaperen" to "Alexandre-Benoit Ofnuts" with setters on first name and last name, your object can temporarily be set to "Marmaduke Ofnuts" or "Alexandre-Benoit Skaperen".

[Skaperen]

my new class has set_opts() and get_opts().  set_opts() works from named options.  get_opts() returns a dict with the options.  an additional feature: set_opts() returns a dict of unrecognized options.  this new class has 8 options (there are not setters or getters for individual options because of so many).

The problem with getters/setters is not code verbosity. It is that they allow inconsistent states. If you rename some "Marmaduke Skaperen" to "Alexandre-Benoit Ofnuts" with setters on first name and last name, your object can temporarily be set to "Marmaduke Ofnuts" or "Alexandre-Benoit Skaperen".

but ... should i change this part of my code?

    def get_opts(self):
        return {
            'gutter':  self.gutter,
            'width':   self.width,
            'height':  self.height,
            'height2': self.height2,
            'top':     self.top,
            'left':    self.left,
            'right':   self.right,
            'bottom':  self.bottom,
        }

    def set_opts(self,**opts):
        for o in option_names_all:
            if o in opts:
                v = opts.pop(o)
                if v != None:
                    setattr(self,'_'+o,v)
        return opts

[Ofnuts]

No, if all the values are completely independent of each other. This said, seeing a dictionary with constant keys usually triggers my named tuple reflex.....

[Skaperen]

what should i do in place of that dictionary of constant keys and/or the function that returns it?

i am thinking of making it be a global to the module and have the get_opts() function return (maybe a copy) of it and also have the set_opts() function use the keys from it in place of option_names_all in the inner loop scanning the passed option, so there just a single place defining what are the options to set and what are the options to get.  it would still by a dictionary with constant keys.

what is a named tuple reflex?