Le Thu, 14 May 2009 17:33:36 -0400, Terry Reedy email@example.com s'exprima ainsi:
To sum up, I think the core of the issue is not about static/dymamic evaluation, or compile time/run time; rather it lies in the fact that python internally does not separate a default *value* from the corresponding local *variable*.
Good try, but you seem to have missed the basic point that underlies at several ways that newbies get tripped up*. Python is an *object* based language, not a *value* based language. By 'value', I mean the information carried by the object. Objects have an identity, values do not. This is a defining characteristic of Python. If one wants an immutable value language, Python is not the right choice.
For immutable objects, the difference is nearly invisible. For mutable objects, which generally do not exist in mathematics (which is generally timeless) the difference is crucial to understand. When people are tripped up by their 'intuition', it is sometimes intuition based on math that does not apply to mutable objects. Names are bound to objects, not to values.
Thank you for this clear reply. Actually, I 101% agree with the object/value discrimination (and even think there should be both in a prog. language, based on the fact that objects have an id and consequently are referenced.)
For functions, parameters are local names, arguments are objects (and not values). Functions may have default objects, not 'default values' (as you say above and elsewhere). If a default object is mutable, it has an initial value, but not a constant value.
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.
Function objects already have an attribute that is a tuple of default objects. (Parameter names, without and with defaults, are part of the code object.)
Python 3.0.1 ,,, on win32
def f(a, b=1, c='1'): pass
Didn't know about that, but it makes a change even easier. (Unfortunately, I haven't py3 installed to play with this.) So, let's change the example to: def storeNums(num, numList=[1,2,3]): numList.append(num) print "list of nums: %s" % numList The issue is obviously that, at call time, python will bind the func local name representing the *actual* parameter numList to the default object (*) defined together with and for the *formal* parameter of the same name numList. So that not only it may be changed, but this changed object will stay as default object and propagate to later calls. The evident solution is to let python get the "data" (to avoid "value") instead of refering to the object -- which implies copying. End of issue?
(*) I use your term and agree it's better when talking of python, but actually it seems that most say "default value", no? Also, value is widely used in the python community, first in official docs, i guess.
Terry Jan Reedy