I can't picture how *not* to define them individually, unless you are thinking of something like
property foo: def get(self): ... def set(self, value): ...
Something like that, yes. The point is that, with the current implementation of properties, any kind of syntactic sugar which *doesn't* group the three methods together somehow goes against the grain.
The rationale for introducing the extended function syntax is that extended functions should be introduced by means of a definition, not of an assignment.
I'm all in favour of that, but as things stand, the extended function syntax only lends itself well to function filters that take a single function as argument. The attempts I've seen so far to extend it to handle more than one function at once all seem prohibitively ugly to me. This means that either (a) we shouldn't try to use the extended function syntax for properties, or (b) properties need to be re-designed so that they fit the extended function syntax better.
So would you also be in favour of defining static methods through
def static foo(): ...
I wouldn't object to it. I also wouldn't object to using the extended function syntax for static and class methods. I just don't want to see some horrible kludge stretching the extended function syntax to places it doesn't naturally want to go. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+