[Python-Dev] Extended Function syntax

[Greg Ewing]

> 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	   +--------------------------------------+