[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
cvrebert at gmail.com
Tue Jan 30 06:23:25 CET 2007
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
> P.S. However, I may be wrong. In that case my syntax suggestion would be
> 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
More information about the Python-ideas