[Python-ideas] fixing mutable default argument values

[Jan Kanis]

On Tue, 30 Jan 2007 20:29:34 +0100, Roman Susi <rnd at onego.ru> wrote:

> Jan Kanis wrote:
>> On Mon, 29 Jan 2007 08:38:39 +0100, Roman Susi <rnd at onego.ru> wrote:
>>
>>> 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.
>>
>>
>> wtf is incremental dynamic semantics, in this context? I did some
>> googling  but all I found referred to techniques related to programming
>> environments. This proposal is just about a change in the language.
>
> Oh, I thought this is very fundamental and well-known as it is the
> second line of Guido's definition of Python:
>
> "Python is an interpreted, object-oriented, high-level programming
> language with dynamic semantics. ..."
>
> As I understand it, it means that statements are read sequencially and
> the semantics of names depends on the flow control.

I never made a link with this description of python and the term  
'incremental dynamic semantics'. Guess I learned something new today.

> The proposal (as it seems to me) wants to make change to the language
> inconsistent with nature dynamic semantics. Its like put implicit:
>
> if RUN_FIRST_TIME:
>     do this
> else:
>     do that
>
> for the same line of code (def statement's first line).
>
>
>> [snip]
>

I'm certainly no proponent of doing something like this. Do note that the  
discussion is between evaluating default expressions at definition time or  
at call time, and the pep entails evaluating default expressions on  
/every/ function call, just like the body of the function is evaluated on  
every call. There's already other code being evaluated at both def time  
and call time, so the proposal does not introduce anything new to pythons  
evaluation model.
IMO having the default exprs evaluate at call time is in no way against  
pythons language design.

>
>> Well, it's good to be clear on where the disagreements lie. However I'm
>> not yet ready to let it rest at that without some more arguments.
>>
>> As Chris pointed out in his first mail, this 'wart' is mentioned on
>> several lists of python misfeatures: [0][1][2]. I'd like to add to this
>> that even the python documentation finds this issue severe enough to
>> issue  an "Important warning"[4].
>>
>> It seems clear that this behaviour is a gotcha, at least for newbies.
>> This  could be excused if there is a good reason to spend the additional
>> time  learning this behaviour, but some of the links state, and my
>
> But as somebody already said the alternative is even worse...
> Its quite easier to mention 3-5 Python warts up front to newbies than to
> introduce subtle exception for semantics and noise words such as "new"
> which do not have any other use elsewhere.

But it's much better to just eliminate the warts without introducing  
subtle exceptions. The pep proposes evaluating default exprs on every  
function call, just like the function body is. No new exceptions are  
introduced. The fact that newbies often expect default values to be fresh  
on every call seems to entail that they won't be surprised a lot when the  
idiom of using default values as caches won't work, if the pep gets  
accepted. Old time pythoneers who know what's new in 3.0 won't be  
surprised either. I'm not in favour of introducing new noise words or  
other new syntax, I just want to 'fix' pythons current semantics.

>> assumption  is, that there are very few situations where re-evaluating
>> causes a  problem and which isn't easily fixable.
>> The semantics which I'd like to have are even easier than the current
>> semantics: everything in a function, be it before or after the colon,
>> is  executed when the function is called.
>> Of course, as Collin Winters pointed out, the burden of proof of
>> showing  that these semantics aren't going to be a problem is still on
>> the pep  proponents.
>>
>
>> So, are there any _other_ arguments in favour of the current semantics??
>
> Repeat the mantra:
>
>     Python's dynamic semantics will not change
>     Python's dynamic semantics will not change
>     Python's dynamic semantics will not change
>
> ;-)

If anything, the proposal is going to _improve_ pythons dynamicness and  
late-bindingness.

Oh, and it's nice to know repeating mantras now count as 'arguments' <wink>

- Jan