On 12/20/2017 03:56 PM, Irv Kalb wrote:
I am trying  to work through the concept of the @property decorator with 
respect to object oriented programming.

I believe that I understand how the @property and @<variableName>.setter work - 
and that they are used to turn what looks like direct access to instance variables 
into method calls in an object.    It seems like these two decorators are essentially 
fancy substitutes for traditional getter and setter methods.  But, I'm having a hard 
time understanding why these names were chosen.

> [snip]

My questions about this are really historical.  From my reading, it looks like using an 
@property decorator is a reference to an older approach using a built in 
"property" function.  But here goes:

1) Why were these decorator names chosen?  These two names @property and @<name>.setter 
don't seem to be very clear to me.  At a minimum, they don't match.  Wouldn't decorator names 
like @<name>.getter and @<name>.setter have been better - more explicit?

2)  Alternatively, if the getter was going to use the @property decorator, then it would 
seem complimentary  to have the decorator name for the associated setter function to have 
the word "property" in its also, something like @propertySetter.

3)  If I create a method with the @property decorator, is there anything else that is implied about 
the name of the method other than you can now refer to the <objectName>.<name> - which 
calls the appropriate method?  My guess/understanding is that in my example above, "salary" 
is considered the property name, which is how you would refer to it outside of the object. Inside the 
class, you use the property name as the name of both the setter and the getter methods.  Is that the 
right way to think about it?


Finally, it seems very odd to me that when you use the @property decorator and the 
@<variableName>.setter, that both of the methods that are decorated need to 
have the same name (but of course different set of parameters.)  As a teacher, this 
seems like it would be an extremely difficult concept to get across to students, as 
this does not work the same way as other Python functions (and methods).  Without a 
decorator, the second function of the same name overrides an earlier function of the 
same name, as in this simple example:

> [snip]
>
Irv


It's because of how Python implements decorators.  When I write

class C:
  def foobar(self):
    pass

I create a binding in the local scope of class C with the name "foobar" that holds a function object. We call this a "local variable" in keeping with other languages, but it's not really the same as it would be in like C, it's a reference in the local namespace to some other object. When I decorate that foobar instead:

class C:
  @property
  def foobar(self):
    pass

That variable now, instead of referencing a function object, references an instance of type 'property' that holds a reference to the original foobar method as it's "_getter". When I expand that to

class C:
  @property
  def foobar(self):
    return self.__foobar

  @foobar.setter
  def foobar(self, value):
    self.__foobar = value

The second decoration calls the 'setter' method of the property instance stored in variable name foobar. That method assigns the new method to the "_setter" of that property instance and returns the updated property, which is assigned redundantly to the variable name foobar.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to