PEP 318: Function Modifier Syntax

Gerrit Holl gerrit at nl.linux.org
Mon Jun 9 15:23:16 EDT 2003


Hi,

Duncan Booth wrote:
> Gerrit Holl <gerrit at nl.linux.org> wrote:
> > I would say:
> > 
> > funcdef: "def" funcname "(" [parameter_list] ")" [call_list] ":"
> > call-list: callable ("," callable)* [","]
> 
> Did you miss out "as" before the [call_list]? Also, I still think that you 
> need to allow optional parentheses around the call-list.

Both true.

So it becomes:

funcdef: "def" funcname "(" [parameter_list] ")" ["as" ["("] call_list [")"]] ":"

> > A legal syntax would be:
> > 
> > def __get(self) as property: ...
> > 
> > However, this doesn't work for set and del. Using function attributes to
> > accomplish properties, as has been proposed in the past, is a different
> > story and would require a different PEP.
> 
> What would people think of a half-way house where the new syntax is used 
> only on the last part of the definition, and you define the other methods 
> just as you do just now?

I think it wouldn't be correct, because we aren't defining __get as
property: __get is only the fget of the property, and the property may
be called italian_lesson.

> Since the property type isn't callable today, I think this just about fits 
> without breaking anything:
> 
> Define a readonly property, implicitly calls property(X) which creates a 
> readonly property:
> 
>    def X(self) as property:
>        return self.__x_value

Yes, that would work. But only because fget is the first argument to
property(), and it is not entirely clear immediately - not to me,
at least.

> Define a readwrite property, the call to property returns a property object 
> which is itself callable. Calling a property object with an fset but no 
> fget would take the parameter as a new fget:
> 
>    def set_X(self, value):
>        ...
>    def X(self) as property(fset=set_X):
>        return self.__x_value

Hm. I am not really convinced whether this is the best solution. It is
not immediatly clear that the property is bound to X, because up til
now, the property was not bound to any of the names of the getter or
the setter. Here, the setter would be accesible as a method but the
getter wouldn't, because X has been overwritten with a property while
set_X hasn't. This is true for all following examples as well.

yours,
Gerrit.

-- 
156. If a man betroth a girl to his son, but his son has not known her,
and if then he defile her, he shall pay her half a gold mina, and
compensate her for all that she brought out of her father's house. She may
marry the man of her heart.
        -- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
	http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
	http://www.sp.nl/





More information about the Python-list mailing list