mutable default parameter problem [Prothon]

[Mark Hahn]

As we are addressing the "warts" in Python to be fixed in Prothon, we have
come upon the
mutable default parameter problem.  For those unfamiliar with the problem,
it can be seen in this Prothon code sample where newbies expect the two
function calls below to both print [ 1 ] :

    def f( list=[ ] ):
            print list.append!(1)

    f()    #    prints [ 1 ]
    f()    #    prints [ 1, 1 ]

It is more than just a newbie problem.  Even experts find themselves having
to do things like this which is a waste of programming effort:

    def f( list = None ):
            if list == None:  list = [ ]

We have three proposals in the Prothon mailing list right now to fix this.
I'd like to bounce these off of the Python list also since this will
possibly make a big difference in Python code ported over to Prothon and we
can always use more advice.

1) Only allow immutable objects as default values for formal parameters.  In
Prothon immutable objects are well-defined since they have an immutable flag
that write-protects them.  This (as the other solutions below) would only
solve the problem in a shallow way as one could still have something like a
tuple of mutable objects and see the problem at a deeper level.  If the
newbie is going to be dealing with something this complex though then they
are dealing with the overall problem of references versus copies and that is
a bigger overall issue.

2) Evaluate the default expression once at each call time when the default
value is needed.  The default expression would be evaluated in the context
of the function definition (like a closure).

3) Evaluate the expression at definition time as it is done now, but at call
time do a defaultValue.copy() operation.  This would be a shallow copy so
again it would be a shallow solution.

Choice 2 is my favorite in that it matches the dynamic nature of Prothon,
but it is an expensive solution.  Choice 1 is the least expensive solution
but it is limiting to the user.  Choice 1 does not help the second code
sample above.  Choice 3 is a good compromise since an object.copy() is
pretty fast in Prothon.

Comments?   How much Python code would these different proposals break?