[Python-Dev] Defining properties - a use case for class decorators? (original) (raw)

Jim Jewett jimjjewett at gmail.com
Tue Oct 18 15:37:12 CEST 2005

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

More information about the Python-Dev mailing list