Thanks to Rob, Cameron, Ian, Chris and Kirill for the detailed explanations.
Very helpful,
Irv
> On Dec 20, 2017, at 3:56 PM, Irv Kalb <i...@furrypants.com> 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.
>
> I have the following example code:
>
>
> class Employee():
>
> def __init__(self, name, salary):
> self.__name = name
> self.__salary = salary
>
> @property
> def salary(self):
> print('Getting salary of', self.__name, 'which is:', self.__salary)
> return self.__salary
>
> @salary.setter
> def salary(self, newSalary):
> print('Setting salary of', self.__name, 'to:', newSalary)
> self.__salary = newSalary
>
>
> # Test code:
> employee1 = Employee('Joe Schmoe', 99999)
> employee2 = Employee('Jane Smith', 123456)
>
> print(employee1.salary)
> print(employee2.salary)
>
> employee1.salary = 100000
> employee2.salary = 222222
>
> print(employee1.salary)
> print(employee2.salary)
>
>
> When it runs, I get the results I expect:
>
> Getting salary of Joe Schmoe which is: 99999
> 99999
> Getting salary of Jane Smith which is: 123456
> 123456
> Setting salary of Joe Schmoe to: 100000
> Setting salary of Jane Smith to: 222222
> Getting salary of Joe Schmoe which is: 100000
> 100000
> Getting salary of Jane Smith which is: 222222
> 222222
>
>
> 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:
>
> def myFunction( ):
> print('In first version of myFunction')
>
> def myFunction( ):
> print('In second version of myFunction')
>
> myFunction()
>
> Which prints: In second version of myFunction
>
>
>
>
> My most recent language before Python was ActionScript 3 (the language of
> Flash). It implemented a similar concept of being able to use what appeared
> to be an explicit data reference which turns into a method call, like this
> example (from StackOverflow):
>
> private var _loggy:String;
>
> public function get loggy ():String
> {
> return _loggy;
> }
>
> public function set loggy ( loggy:String ):void
> {
> // checking to make sure loggy's new value is kosher etc...
> _loggy = loggy;
> }
> This syntax made the concept easy to understand and implement in an
> ActionScript class (even though it also uses the same name for both function).
>
> I do NOT want to start any kind of language flame war. I am really just
> trying to understand the reasons behind why this concept is implemented in
> Python this way, so that I can wrap my head around it and teach it
> effectively in my classes.
>
> Irv
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
