spir wrote:
Right. But this does not imply that a local variable must point to the same object that deals as default. This is actually the point I tried to make; but obviously not clear enough. It simply requires that while evaluating a function definition python caches defaults in a separate "storage place" that will not be later affected by the use of local variables. E.g. updating a 'number_list' local name binding should not update a default value/object for the corresponding parameter, if any.
There are only two ways to make that happen though: 1. Evaluate the default argument expression at function call time instead of definition time 2. Actually *copy* the default argument to create the object referenced by the parameter on a given invocation Since option 1 will work for any arbitrary object, while option 2 is limited to objects which support copy.copy (or copy.deepcopy, depending on the copying semantics chosen), the "late evaluation of default arguments" (option 1) approach is the more promising angle of attack by far. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------