Accessors in Python (getters and setters)

[Marc 'BlackJack' Rintsch]

In <1153371049.561672.233550 at h48g2000cwc.googlegroups.com>, mystilleef
wrote:

> 
> Bruno Desthuilliers wrote:
>> mystilleef wrote:
>> > Bruno Desthuilliers wrote:
>> >
>> > Because you don't want third parties illegimately tampering with an
>> > object's internal data and thus crashing your system?
>>
>> Let's try again...
>>
>> point 1 : there's *no* language-inforced access restriction in Python.
>> Just a *convention*.
>>
> 
> Huh? What are properties for then?

To have a tool to change the default accessor into something more
complicated, a calculated attribute, without the need to change the API.

>> point 2 : so anyone *can* "illegimately tampering with an object's
>> internal data" at will.
>>
> 
> And this is robust how?

That's as robust as the consenting adults that use that code.  And as
robust as Java where you can get at private attributes via reflection and
C++ where you can simply define private as public.

>> point 3 : anyway it's not *my* system that will then crash - but the
>> system of the one who "illegimately" played with my package's objects
>> internals. And as far as I'm concerned, it's none of my problem - they
>> were marked as implementation, so anyone playing with them is on it's
>> own. FWIW, I suspect that if someone want to muck with implementation,
>> he certainly has a good legitimate reason to do so, and will do her best
>> to not break anything. Else he's a complete idiot and there's no cure
>> for this.
>>
> 
> You can't be serious. Please tell me you are joking.

No he's not joking.  If programmers don't read the "stop here, this is
internal" signs and carelessly change states then there's a much bigger
problem than access control.  The problem is with the programmer, not the
language.

>> point 4 : since we have computed attributes, turning a "public data
>> attribute" (to use your idiom) into a "private/protected data attribute
>> with accessors" *without breaking the interface* is not even a non-brainer.
>>
>> Now, please, can you explain the difference between :
>>
>> class Complicated(object):
>>   def __init__(self, data):
>>     self.data = data
>>   def _get_data(self):
>>     return self._data
>>   def _set_data(self, data):
>>     self._data = data
>>
>> and
>>
>> class Pragmatic(object):
>>   def __init__(self, data)
>>     self.data = data
>>
>>
>> and find any *valid* reason to use the first solution instead of the
>> second ? ('that's what the book says' not being a valid reason).
>>
> 
> 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")
> 
> 	def monitor_events(self):
> 		# Only methods of this class can change __is_active.
> 		# Add code to change __is_active here.
> 		return
> 
> See! I'm controlling access. Whee!

No you don't.

obj = Robust()
obj._Robust__is_active = 42

The name munging is not meant to provide access control but to avoid name
clashes when dealing with deep inheritance hierarchies or mixin classes.

A pythonista would just call the attribute `_is_active` and rely on the
common sense of other programmers not to play with it at will.

> 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.

If it's called `_is_active` then the access to it should not be spread
over 27000 lines.  You don't access attributes not belonging to the API
from everywhere in the code base.  If you do, you are a bit careless as a
programmer, don't you think?

> 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."

The name `_is_active` tells that it's not API.  If the naïve third party
does not respect this than it's on its own.  The solution is indeed to
tell that to them because otherwise they will get into trouble when they
continue to program in Python where this is the common way to make things
"private".

> 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.

You shouldn't waste your time with Python then.  The language is obviously
not "bondage" enough for your needs.

Ciao,
	Marc 'BlackJack' Rintsch