[Python-ideas] Default arguments in Python - the return

[spir]

Le Sat, 9 May 2009 16:06:06 -1000,
Carl Johnson <cmjohnson.mailinglist at gmail.com> s'exprima ainsi:

> I think this is a case where there are pros and cons on both sides.
> There are a lot of pros to the current behavior (performance,
> flexibility, etc.), but it comes with the con of confusing newbies and
> making people go through the same song and dance to set a  "sentinel
> value" when the want the other behavior and they can't ensure that
> None won't be passed. The newbie problem can't be fixed from now until
> Python 4000, since it would break a lot of existing uses of default
> values, but we could cut down on the annoyance of setting and check a
> sentinel value by introducing a new keyword, eg.
> 
> def f(l=fresh []):
>    ...
> 
> instead of
> 
> __blank = object()
> def f(l=__blank):
>    if l is __blank:
>        l = []
>    ...
[...]

Maybe the correctness of the current behaviour can be checked by a little mental experiment.

=======
Just imagine python hasn't default arguments yet, and they are the object of a PEP. An implementation similar to the current one is proposed. Then, people realise that in the case where the given value happens to be mutable _and_ updated in the function body,... What do you think should/would be decided?

-1- Great, we get static variables for free. It is a worthful feature we expected for a while. In numerous use cases they will allow easier and much more straightforward code. Let's go for it.

-2- Well, static variables may be considered useful, in which case there should be a new PEP for them. Conceptually, they are a totally different feature, we shall certainly not mess up both, shall we?
=======

I bet for n°2, for the reasoning of people stating it's a major gotcha will be hard to ignore. But may be wrong. Still, default arguments actually *are* called "default arguments", which means they should be considered as such, while they do not behave as such in all cases.
Now, we must consider the concrete present situation in which their real behaviour is used as a common workaround. I do not really understand why default args are used as static vars while at least another possibility exists in python which is semantically much more consistent:

### instead of "def callSave(number, record=[])"
### just set record on the func:
def callSave(value):
   callSave.record.append(value)
   return callSave.record
callSave.record = []
print callSave(1) ; print callSave(2) ; print callSave(3)
==> 
[1]
[1, 2]
[1, 2, 3]

Also, func attributes are an alternative for another common (mis)use of default arguments, namely the case of a function factory:

def paramPower(exponent):
   ### instead of "def power(number, exponent=exponent)"
   ### just set exponent on the func:
   def power(number):
      return number**power.exponent
   power.exponent = exponent
   return power
power3 = paramPower(3) ; power5 = paramPower(5)
print power3(2) ; print power5(2)
==>
8
32

In both cases, tha notion of a func attribute rather well matches the variable value's meaning. As a consequence, I find this solution much nicer for a func factory as well as for a static variable.

Denis
------
la vita e estrany