On Thu, Jul 2, 2020 at 8:38 PM Greg Ewing email@example.com wrote:
On 2/07/20 9:45 pm, Chris Angelico wrote:
On Thu, Jul 2, 2020 at 7:41 PM Alex Hall firstname.lastname@example.org wrote:
On Thu, Jul 2, 2020 at 11:33 AM Chris Angelico email@example.com wrote:
What's the idea being discussed? AIUI there's no need or request to change the language/stdlib, but maybe I'm misreading.
Ah, now I understand. I did automatically assume that Greg was proposing adding this to the stdlib or something, but maybe I only assumed that because it was in the list.
Could be that I'm the one misunderstanding here, but only Greg can answer that question :)
I was thinking something like it might become a candidate for stdlib inclusion, if it wasn't universally hated for abusing the class statement.
Let's get concrete then. Suppose that the property constructor recognized a special one-argument form: if it has an fget attribute, it fetches its details from the fget, fset, fdel, and __doc__ attributes of that object. That way, it can be used in three ways: a standard constructor that does all the work with up to four arguments, the decorator form (which is the same as the one-arg form initially, but then you can use its setter decorator), and the class form.
class Test: x = property(lambda self: 42, lambda self, val: print("Setting to", val))
@property def y(self): return 42 @y.setter def y(self, val): print("Setting to", val)
# the theoretical one @property class z: def fget(self): return 42 def fset(self, val): print("Setting to", val)
Since functions won't normally have fset attributes, this should be fairly safe - technically it'd be backward incompatible, but it's highly unlikely to break any real-world code.
I don't write a lot of properties with setters, so I can't speak to the value of this, but it is at least plausible.
(If you'd prefer to use "get" or "getter" or something in place of "fget", that would work fine. I used the same name as the keyword arg to property itself, but it can be anything.)