Accessors in Python (getters and setters)

[Steve Holden]

Gerhard Fiedler wrote:
> On 2006-07-20 04:15:33, 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()
>>
>>acceptable and
>>
>>   some_robust.__is_active
>>
>>somehow dangerous (ignoring the fact that name_mangling will take place) 
>>is what?
>>
>>
>>>	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.
> 
> 
> I'm not sure, but there's one thing that has a potential to be the real
> issue: what's the common way to create a property that is read-write for
> the implementation and "read-only" for the interface? It seems to me that
> this is what mystilleef is trying to do.
> 
> I know that Python doesn't really provide access control. But so far I've
> learned that a leading underscore says "I'm implementation, don't touch me
> unless you know what you're doing". So I imagine that I browse through code
> and look for leading underscores for non-local object attributes, to spot
> troublespots. So I imagine that using such attributes as "read-only"
> interface elements may not be a good idea, because then you not only have
> to spot them in outside code, you always also have to check whether that's
> a read or a write access (to know whether it's something potentially
> dangerous or not). I also don't know how you could use the computed
> attribute methods to do different things for access from the outside and
> from the inside (of the object).
> 
> So... _is_active is considered implementation. Don't mess with me, it says.
> But the users of the class need access to it: read access. Do you just say
> "read access isn't changing anything, so just use _is_active"? The
> disadvantage is that the outside code is sprinkled with accesses to
> attributes with leading underscores, which I assume looks kind of scary. Or
> do you rename _is_active to is_active, indicating that access to it is
> indeed allowed? Then you would have to do something in the attribute
> accessors to control the write access -- because that still isn't a good
> idea. But I need want to be able to write to it from inside the class...
> but how, if the attribute accessor is preventing that? Is there a local
> override for that? I'm sure there is... but is it a common technique?
> 
> I may have not used the correct terminology for everything, but I think
> it's possible to parse that :)
> 
> And maybe that helps putting this to rest and make everybody happy :)
> 
The logical way would seem to be to provide a read property is_active() 
only. The implementation can access the _is_active instance variable 
that the property exposes, writing it as necessary. If the accessor 
gives direct access to the variable there's no need to use it inside the 
object implementation. Or have I misunderstood your requirements?

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb       http://holdenweb.blogspot.com
Recent Ramblings     http://del.icio.us/steve.holden