Home Original page

properties and get/set methods

Mike C. Fletcher mcfletch at rogers.com
Sat Apr 5 23:48:41 EST 2003 
Dan Bishop wrote:

>Timothy Grant <tjg at craigelachie.org> wrote in message news:<mailman.1049581810.25706.python-list at python.org>...
>  
>
...

>>Is it possible to determine which attribute was used to as the trigger for the 
>>call to setvar() or getvar()? so that set_appropriate_attribute() or 
>>appropriate_attribute() can set the correct attribute or get the correct 
>>attribute?
>>    
>>
>
>Why not just use two different getvar and setvar functions?
>

When you're doing generic "framework" level programming, it's just not 
acceptable to have to define 2 (really 3) new functions for every 
property.  Compare:

    def setMyProperty( self, value ):
       do_the_generic_thing( self, 'myProperty', value)
       self.__dict__["myProperty"] = value
    def getMyProperty( self ):
       do_the_generic_thing( self, 'myProperty', value)
       return self.__dict__["myProperty"]
    def delMyProperty( self ):
       del self.__dict__[ "myProperty" ]
    myProperty = property( getMyProperty, setMyProperty, delMyProperty, 
"""Some documentation""")

versus:

    myProperty = StringProperty(
       "myProperty", """Some documentation""",
       defaultValue = "this value",
    )

In these cases, you're using properties to simplify the modelling of 
domain objects, or to provide some *generic* functionality over and 
above a regular value get/set.  You don't want to have to specify that 
functionality for every property, you just want to say "this is one of 
_those_ properties".  The code bloat (not to mention mindless 
duplication of code) when you get up to 15 or 20 properties for an 
object would be ridiculous.

As for how the problem ((a deficiency in the property API IMO) of not 
knowing the name being set/get within the get/set methods) gets worked 
around.  I (as seen above) do some comparatively minor (but still 
annoying) duplication of code by passing an explicit string version of 
the name to the property sub-class's constructor and then use that name 
when the property instances are called.  Technically, the string value 
can be anything, and certain sub-classes of property just ignore it, 
while in any case, it can be something different than the "public" name 
through which the property API calls were made :( .

i.e. this works, storing the value as instance.__dict__['_myProperty']:

    myProperty = StringProperty(
       "_myProperty", """Some documentation""",
       defaultValue = "this value",
    )

but the property doesn't know what name it's _really_ being accessed as 
in this case :( .

For the particular case of the original poster, where the 
number/complexity of things being done can be modelled with a single 
function that dispatches on the property name, consider overriding 
__getattribute__ and __setattr__, doing the generic operations where 
appropriate, then call the superclass' implementation

Enjoy,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/
More information about the Python-list mailing list