>> If you thought not reevaluating function expressions
>> was confusing for newbies, wait until you see what making up a new
>> kind of yield will do for them.

>> Why not just push for some decorators that do this to be included in
>> stdlib? I see the utility, but not the point of adding extra syntax.

> Even if a decorator solution can be made to work, it seems to me that
> the difficulty with a decorator solution is that it is
> all-or-nothing -- you can decorate the entire parameter list, or none
> of the parameters, but not some of the parameters. You can bet that
> people will say they want delayed evaluation of some default arguments
> and compile-time evaluation of others, in the same function definition.

> There are work-arounds, of course, but there are perfectly adequate
> work-arounds for the lack of delayed evaluation defaults now, and it
> hasn't stopped the complaints.

> I'm going to suggest that any syntax should be applied to the formal
> parameter name, not the default value. This feels right to me -- we're
> saying that it's the formal parameter that is "special" for using
> delayed semantics, not that the default object assigned to it is
> special. Hence it should be the formal parameter that is tagged, not
> the default value.

> By analogy with the use of the unary-* operator, I suggest we use a new
> unary-operator to indicate the new semantics. Inside the parameter
> list, &x means to delay evaluation of the default argument to x to
> runtime:

> def parrot(a, b, x=[], &y=[], *args, **kwargs):

> As a bonus, this will allow for a whole new series of bike-shedding
> arguments about which specific operator should be used. *grin*

> Tagging a parameter with unary-& but failing to specify a default value
> should be a syntax error:

> def parrot(&x, &y=[]):

> Likewise for unary-& outside of a parameter list.

> Bike-shedding away... *wink*