Death to tuples!

[Antoon Pardon]

On 2005-11-30, Duncan Booth <duncan.booth at invalid.invalid> wrote:
> Antoon Pardon wrote:
>
>>> The left one is equivalent to:
>>>
>>> __anon = []
>>> def Foo(l):
>>>    ...
>>>
>>> Foo(__anon)
>>> Foo(__anon)
>> 
>> So, why shouldn't: 
>> 
>>    res = []
>>    for i in range(10):
>>       res.append(i*i)
>> 
>> be equivallent to:
>> 
>>   __anon = list()
>>   ...
>> 
>>    res = __anon
>>    for i in range(10):
>>       res.append(i*i)
>
> Because the empty list expression '[]' is evaluated when the expression 
> containing it is executed.

This doesn't follow. It is not because this is how it is now, that that
is the way it should be.

I think one could argue that since '[]' is normally evaluated when
the expression containing it is excuted, it should also be executed
when a function is called, where '[]' is contained in the expression
determining the default value.

>>> The left has one list created outside the body of the function, the
>>> right one has two lists created outside the body of the function. Why
>>> on earth should these be the same?
>> 
>> Why on earth should it be the same list, when a function is called
>> and is provided with a list as a default argument?
>
> Because the empty list expression '[]' is evaluated when the 
> expression containing it is executed.

Again you are just stating the specific choice python has made.
Not why they made this choice.

>> I see no reason why your and my question should be answered
>> differently. 
>
> We are agreed on that, the answers should be the same, and indeed they are. 
> In each case the list is created when the expression (an assigment or a 
> function definition) is executed. The behaviour, as it currently is, is 
> entirely self-consistent.

> I think perhaps you are confusing the execution of the function body with 
> the execution of the function definition. They are quite distinct: the 
> function definition evaluates any default arguments and creates a new 
> function object binding the code with the default arguments and any scoped 
> variables the function may have.

I know what happens, I would like to know, why they made this choice.
One could argue that the expression for the default argument belongs
to the code for the function and thus should be executed at call time.
Not at definion time. Just as other expressions in the function are
not evaluated at definition time.

So when these kind of expression are evaluated at definition time,
I don't see what would be so problematic when other functions are
evaluated at definition time to.

> If the system tried to delay the evaluation until the function was called 
> you would get surprising results as variables referenced in the default 
> argument expressions could have changed their values.

This would be no more surprising than a variable referenced in a normal
expression to have changed values between two evaluations.

-- 
Antoon Pardon