2017-12-21 2:56 GMT+03:00 Irv Kalb <i...@furrypants.com>: > 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? >
There are nothing special with decorators, the are simply functions which take at least one argument (of course they can be implemented as classes, but lets make things simple), and *`@decorator*` is a syntactic sugar for *`func = decorator(func)`*. As I see it, the primary idea to introduce them in Python was readability, and possibility for special syntax highlighting and nothing more. To sum it up, while* `property*` is often used as a decorator, the `*property`* built-in is actually a class. So it is not "*an older approach using a built in "property" function*" but in reality it is the same class as it was but can be applied with new decorator syntax. And defined in stdlib as *`class property(fget=None, fset=None, fdel=None, doc=None)`*. 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: > This is not true, actually they all work the same way following *descriptor protocol* - the mechanism behind properties, methods, static methods, and others. It is not simple topic, but it essential, I will provide some references which can help you to grasp: Descriptor HowTo Guide <https://docs.python.org/3/howto/descriptor.html> brilliant tutorial by Raymond Hettinger, which is a part of official documentation. It is very well written, but if you need more on this topic this books helped me a lot: "*Python in a Nutshell, 2E by Alex Martelli*" while this book covers Python 2.5, the key idea of descriptors was introduced as a part of new style classes in Python 2.2. "*Python Cookbook, 3E by David Beazley and Brian K. Jones*" covers Python 3 with a lot of practical examples. "*Fluent Python by Luciano Ramalho*" especially Chapter 20, but my advise to read the book sequentially. With kind regards, -gdg -- https://mail.python.org/mailman/listinfo/python-list
