Greg Ewing wrote: >> ... the standard way of defining properties at the moment >> leaves something to be desired, for all the same reasons >> that have led to @-decorators.
Guido write: > ... make that feeling more concrete. ... > With decorators there was a concrete issue: the modifier > trailed after the function body, in a real sense "hiding" > from the reader. I don't see such an issue with properties. For me, the property declaration (including the function declarations) is too verbose, and ends up hiding the rest of the class. My ideal syntax would look something like: # Declare "x" to name a property. Create a storage slot, # with the generic get/set/del/doc. (doc == "property x"?) property(x) # Change the setter, possibly in a subclass property(x) set: if x<5: __x = x If I don't want anything special on the get, I shouldn't have to add any "get" boilerplate to my code. An alternative might be slots=[x, y, z] to automatically create default properties for x, y, and z, while declaring that instances won't have arbitrary fields. That said, I'm not sure the benefit is enough to justify the extra complications, and your suggestion of allowing strings for method names may be close enough. I agree that the use of strings is awkward, but ... probably no worse than using them with __dict__ today. -jJ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com