[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments

[Chris Rebert]

Roman Susi wrote:
> Hello!
> 
> I'd liked to say outright that this bad idea which complicates matters 
> more than provides solutions.
> Right now it is enough to know that the part from def to ":" is executed 
> at definition time. This is what
> incremental dynamic semantics is about. So, the suggestion is good only 
> as separated feature, but is IMHO wrong
> if considered in the language design as a whole.

You're entitled to your own opinion on the PEP.

> So things like
> 
> def foo(non_const=None):
>    non_const = non_const or []
> 
> are good becuase explicitely tell you that the mutable object is to be 
> created at call-time, not def-time.

The 'new' (or similar) keyword (might) indicate the new semantics, or 
alternatively, 'old' (or a similar) keyword (might) indicate the old 
semantics. If the new semantics become the default (as the PEP 
proposes), then this point is moot anyway as it will be explicit by way 
of the language definition.

> And I do not like PEP 3107 neither: its overly complex.
> 
> If there is a need for Python type checking, I'd suggested to make a 
> special superset which could be used
> to write compiled extensions as well (Pyrex comes to mind).

That's not part of my proposal, nor does my PEP depend on that one. I 
merely mention PEP 3107 when considering compatibility with other 
3100-series PEPs.

> P.S. However, I may be wrong. In that case my syntax suggestion would be 
> this:
> 
> def foo(non_const or []):
>    ...
> 
> where [] is executed at runtime BECAUSE at def time non_const is somehow 
> True and that is enough to leave [] alone.
> I have not checked, but I believe it is backward compatible.
> Anyway, could you summarize both contr-argument and this syntax proposal 
> in the PEP?

I don't quite understand exactly how this would work and would like more 
details on it, but once you've explained it, of course I'd be happy to 
include it in the next draft.

- Chris Rebert