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
