Accessors in Python (getters and setters)

Bruno Desthuilliers onurb at xiludom.gro
Wed Jul 19 12:54:55 EDT 2006


mystilleef wrote:
> Bruno Desthuilliers wrote:
> 
>>mystilleef wrote:
(snip)
>>>>>
>>>>>Of course using setters for the sake of just using them is pointless.
>>>>
>>>>Indeed.
>>>>
>>>>
>>>>
>>>>>The reason to use them is if pre-conditions or post-conditions need to
>>>>>be met. Or to control access to an objects states.
>>>>
>>>>Then why advocate *systematic* use of them ?
>>>>
>>>>(snip)
>>>
>>>I never advocated anything.
>>
>>You advocated
>>"""
>>1). Make all attributes of a class private/protected .
>>2). If a "non-callable" attribute is going to be used outside a class,
>>think about making it a property and name the property well, because
>>you never know...
>>"""
>>
> 
> 
> You use accessors when you need to control access to a data attribute.

Indeed. And when you don't need too ? (the second 'o' is not a typo)

> That's not advocacy, that's common sense.

I'm afraid we don't use the same definition of "common sense". Writing
useless code is not part of my definition of "common sense".

(snip)
>>>
>>>I agree. And I already told you I think in terms of state and behavior
>>>and not language dependent semantics.
>>
>>Then why do you advise "(making) all attributes of a class
>>private/protected" and systematically using properties ?
>>
> 
> 
> 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*.

point 2 : so anyone *can* "illegimately tampering with an object's
internal data" at will.

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.

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


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"



More information about the Python-list mailing list