On: Python's Mutable Default Problem

[sjs]

Precisely because Python has late binding you would expect the parameters to be evaluated on each call to the function.

One thing Python lacks is the ability to use preceding arguments in defaults, e.g. you cannot do this:

    def f(a=3, b=a+1):
        return (a + b) / 2
    
    NameError: name 'a' is not defined

Oops.

[beza1e1 → sjs]

There is no order for named arguments. You could call the function like this after all:

  f(b=3)

[wingo → beza1e1]

Of course; in that case the default value expression for `b' would not be evaluated.

Common Lisp does this right.

[crystalis → sjs]

That hides default logic in the signature. Why would you favor that over

  def f(a=3, b=None):
    b = b or a+1 # or use a more explicit version
    return (a + b) / 2

[chc → crystalis]

That is code is logically convoluted — that's one reason not to love it. Why do you think is the more straightforward statement, just in general?

- "Let B be one greater than A unless otherwise specified."

- "We have no default value for B. If B has a value, then let B be equal to that value. If B does not have a value, then let B be one greater than A."

[sjs → crystalis]

Because that can be said more succinctly. It is even easier to read as there is less to read, which I realize is mostly subjective.

[crystalis → sjs]

I'm pretty sure this is the same argument used to make Perl a bad guy.

[sjs → crystalis]

I disagree, but we've gotten a bit off topic.

I think Python's behaviour is confusing and basically never what anyone actually wants. Regardless of whether or not you can use other params in defaults, the defaults should be evaluated on each call.