Skip> x = 42
Skip> def x(self) [propget]:
Skip> "Doc string for x"
Skip> return self.__x
Guido> It's broken. I expect this to raise an exception at some point.
Guido> Beyond that, who cares?
Jim> If so, then this decorator is a bad idea.
Jim> I would expect 42 to be the initial value of the property x.
Skip> Then it makes sense to put "x = 42" after the three property
Skip> definitions (before the end of the class definition).
Skip> Would that work?
Not really. The documentation says
"Properties are a neat way to implement attributes whose usage
resembles attribute access, but whose implementation uses method
calls."
This suggests that creating a property creates a manager. In this case,
the manager is created for an attribute that already exists. If it uses
the previous value as the initial current value, that is what I expect.
If it raises an exception ("I can't manage that! Someone beat me to it!"),
I'll be annoyed, but live with the limitation. If it silently throws the
value away, or raises an exception at run time -- that is bad.
Yes, this is a variation on the "Properties do not work for classic
classes, but you don't get a clear error when you try this." wart.
But the code this decorator replaces::
x = property(getx, setx)
does explicitly replace x, so I think *this* confusion may be specific
to the decorator.
-jJ
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4