Roman Susi wrote:
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