Accessors in Python (getters and setters)

[mystilleef]

Steve Holden wrote:
> mystilleef wrote:
> [...]
> >
> > I don't know it's your code not mine.
> >
> > class Robust(object):
> >
> > 	def __init__(self):
> > 		# Arbitrarily changing this state to False will crash app or will
> > 		# corrupt the whole event system.
> > 		self.__is_active = True
> >
> > 	def get_is_active(self):
> > 		return self.__is_active
> >
> > 	buffer_is_active = property(get_is_active, doc="True if buffer is
> > editable")
> >
> Let's ignore changes of state for the moment. The mystical difference
> that makes read access via
>
>    some_robust.buffer_is_active()
>

buffer_is_active is not a method, it's a property. So:

some_robust.buffer_is_active

is appropriate.

> acceptable and
>
>    some_robust.__is_active
>
> somehow dangerous (ignoring the fact that name_mangling will take place)
> is what?
>

We can't ignore name mangling. That's an illegal statement in Python.
So it is less dangerous.

> > 	def monitor_events(self):
> > 		# Only methods of this class can change __is_active.
> > 		# Add code to change __is_active here.
> > 		return
> >
> I'm sure nobody would argue that if close synchronization between
> multiple attributes is required then write accessors are a bad idea. But
> using them unnecessarily just makes your code heavier, slower and less
> easy to maintain.
>

Ah, I broke my own rule. That method is supposed to be private too.
Meaning no one can change the state of the object except the object
itself. The code is below

    def __monitor_event(self):
        # Perform whatever needs to be done to change state
        return

__monitor_event is not supposed to be a write accessor. My point was
show how you can change the state of an object internally without
needing external access to it. Since some people are surprisingly
claiming it is not possible.

> > See! I'm controlling access. Whee! And if one sober morning I want to
> > change the name __is_active to __buffer_is_active, I won't have to hunt
> > down 27000 lines of code to do it. Also a naive third party won't crash
> > my system by changing Robust's state arbitrarily. Because in the real
> > world when your program is buggy, you get bug reports, nasty emails
> > among other forms of ridicule. And your supposed solution to my problem
> > is me saying, "but...but...I told you not change is_active." Ha! And if
> > you can't figure out why anyone would do this, then I'm not wasting my
> > time here anymore. Someday you'll learn the hard way.
> >
> It's way too late. My comments *are* based on engineering experience.
> One day you may realise that unnecessary complexity is a far bigger time
> waster than any imagined problems of direct attribute access. I suspect
> that if you are getting complaints if the nature you describe it's just
> because your software isn't that good.
>

And mine are based on future engineering predictions? Okay, one day I
shall see the light.

> > Thanks to the people who exposed me to Python's properties.
> >
> > Bye
> >
> Really? Promise? I fear we are arguing from different premises.
>

Yes, we are. We have been since about the 5th post on this thread if
you haven't noticed.