[Python-ideas] fixing mutable default argument values

[Jan Kanis]

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.


On Sat, 27 Jan 2007 06:30:00 +0100, Josiah Carlson <jcarlson at uci.edu>  
wrote:
> "Jan Kanis" <jan.kanis at phil.uu.nl> wrote:
>> I hope we agree
>> that the problem we're trying to solve is that while
[snip]
> I'm going to have to disagree on the 'non-intuitive and ugly' claim.  We
> are just going to have to agree to disagree.
>

On Mon, 29 Jan 2007 08:38:39 +0100, Roman Susi <rnd at onego.ru> 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.


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 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.

On the other hand, are there really any good reasons to choose the current  
semantics of evaluation at definition time? What I've heard basically  
boils down to two arguments:
- "let's not change anything", i.e. resist change because it is change,  
which I don't think is a very pythonic argument.
- Arguments based on the assumption that people actually do make lots of  
use of the fact that default arguments are shared between function  
invocations, many of which will result in (much) more code if it has to be  
transformed to using one of the alternative idioms. If this is true, it is  
a valid argument. I guess there's still some stdlib grepping to do to  
decide this.

So, are there any _other_ arguments in favour of the current semantics??


- Jan


[0] 10 Python pitfalls (http://zephyrfalcon.org/labs/python_pitfalls.html)
[1] Python Gotchas
(http://www.ferg.org/projects/python_gotchas.html#contents_item_6)
[2] When Pythons Attack
(http://www.onlamp.com/pub/a/python/2004/02/05/learn_python.html?page=2)
[4] Python manual - 4. More control flow tools  
(http://docs.python.org/tut/node6.html#SECTION006710000000000000000)