Fwd: property decorator?

[Kirill Balunov]

2017-12-21 2:56 GMT+03:00 Irv Kalb <Irv at 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