The problem with mutable defaults is that they are evaluated once only when the function is defined. Each time the function is called you'll be using the same mutable variable that was created during function definition.
To the curious - SO has an explanation of why Python was designed like this, which I found interesting: http://stackoverflow.com/questions/1132941/least-astonishmen...
Actually, this is not a design flaw, and it is not because of internals, or performance. It comes simply from the fact that functions in Python are first-class objects, and not only a piece of code.
Why in Common Lisp defaults behave the way one would expect, then? Functions are also first class, but defaults are evaluated at every call.
def foo():
def bar():
...
return bar
foo() == foo() # false
I don't know how CL works in this regard, nor do I know which is better or worse. I think the explanation linked did a terrible job conflating first class functions with execution and runtime models. Some of the answers below it explain better tho. :)
When the function represented by the lambda expression is applied to arguments, the arguments and parameters are processed in order from left to right. (...) If optional parameters are specified, then each one is processed as follows. If any unprocessed arguments remain, then the parameter variable var is bound to the next remaining arguments, just as for required parameter. If no arguments remain, however, then the initform part of the parameter specifier is evaluated, and the parameter variable is bound to the resulting value (...).
The CLTL2 specifies that the form representing the default value of optional parameter shall be evaluated every time the parameter is not provided.
They can also be good. Here's an example from the Reddit discussion, showing how a mutable default can be used to very neatly and cleanly add memorization to a function:
def fib(n, m={}):
if n not in m:
m[n] = 1 if n < 2 else fib(n-1) + fib(n-2)
return m[n]I won't say it would be clear anyone that reads it, because we live in a world where people who claim to be programmers can't do fizz buzz.
Add a @memoize decorator and do it there, you need to always be as obvious as possible. Compare:
@memoize
def fibonacci(n): pass
def fibonacci(n, memory=[]): pass
def fib(n, m:"donotusethisparameter"={}): def f(seq=[]):
for x in seq:
# do somethingPass all code under pylint scrutiny, comply to its complains or adjust its rules, do it early. That is the recommendation I wish all devs could read.
def f(x=0, y="foo", z=3.14159):
def f(L=None):
if L is None:
L = []
def f(L=()):
... >>> def f(x):
... return x + 5
>>> type(f)
<type 'function'>
>>> dis.dis(f.func_code)
2 0 LOAD_FAST 0 (x)
3 LOAD_CONST 1 (5)
6 BINARY_ADD
7 RETURN_VALUE
>>> g = f
>>> g(10)
15
>>> g is f
True
>>> import socket
>>> socket.gethostbyname('www.google.com')
'74.125.71.103'
>>> socket.gethostbyname = lambda i: '10.0.0.1'
>>> socket.gethostbyname('www.google.com')
'10.0.0.1'
Functions just being variables has useful properties when you're doing something like fancy switch/case type things (the readability of this is questionable, but it's cool to look at it, like a Duff's device):
>>> i = 1
>>> { str: func1, unicode: func2, int: func3 }.get(type(i), func1)(i)
in func3
>>> def maker(i):
... def ret(x):
... return x + i
... return ret
>>> f, g = maker(10), maker(100)
>>> f(5), g(10)
(15, 110)
By useful he means mucking up your program in totally unexpected ways.
He's being nice about it being a silly decision to have it behave that way. The entire post reads more like a list of unexpected things that will bite you in the ass.
You can use a mutable default argument as an ersatz static variable, e.g. for memoization.
Maybe I misunderstood you, but they are perfectly mutable:
class A
attr_accessor :a
def initialize
@a = []
end
def b x = a
x << 1
end
end
obj = A.new
# => #<A:0x007fd92b2e9850 @a=[]>
obj.b
# => [1]
obj.b
# => [1, 1]
obj.a
# => [1, 1]
a = 0
# => 0
x = lambda {|y = (a + 1)| y }
# => #<Proc:0x007fd92b1dae50@(irb):33 (lambda)>
x[]
# => 1
a = 5
# => 5
x[]
# => 6 ruby> class A; end
=> nil
ruby> def foo(bar = A.new); return bar; end
=> nil
ruby> foo
=> #<A:0x00000101985060>
ruby> foo
=> #<A:0x0000010197a6b0>
I've even seen a major Python library with this bug (I'm sorry, I don't recall which off-hand). It's really surprising behavior for new Python devs.
Basically, sometimes you do want to reuse the mutable between function calls, and in those cases it can save a fair bit of code passing it in repeatedly.
def calculate(a, b, c, memo={}):
try:
value = memo[a, b, c] # return already calculated value
except KeyError:
value = heavy_calculation(a, b, c)
memo[a, b, c] = value # update the memo dictionary
return valuedef f(L=None): L = L or []
These are the little assumptions that keep blowing off my feet. Thanks.
def f(x=None): x if x is not None else [] def f(x=None): if x is None: x = []That said, people still seem to favor your form as the more Pythonic way. Personally, I think that's just because the ternary expression is relatively new.
But if this expression is a line in a larger function, and is intended to reset the value of argument x if no other value is passed in for it, does this really act as an assigment to x? Because I sort of read this expression as evaluating to some value -- the passed value for x, or a [] -- but does this assign that value to the argument x? Or must it be x = [expression]
def f(x=None):
x = x if x is not None else []
return x
L = [] if L is None else LNot to say I think python should be changed on this point. It shouldn't, there are code checkers that warn you on the gotcha, let's use them.
If you say "f(x=[])" (assuming that worked without the actual side effects it has), someone could still say "x(None)" instead of "x()", causing the function to die. Since a robust program isn't able to avoid checking for None, it might as well set defaults there too.
There is another case where this is important; you might want the equivalent of "f(x=expensive_function_to_calculate_useful_default())", and you don't want that function called unless it needs to be. Only the x=None approach allows this to be deferred.
In the expensive case, I'd just calculate it once and store it somewhere (possibly as a lookup dictionary if there are multiple inputs) and access that from within the function.
But None is a result that can happen in situations that would otherwise return exactly the expected type. If "nothingness" can be meaningful (especially in a function that accepts an empty list as a parameter, say), it's nicer if the code just deals with None itself instead of requiring checks for None in all the callers.
> (defvar *fn*
(let ((x 3))
(lambda (&optional (y (list nil x)))
(push 7 (car y)) ; modifies the list
y)))
*FN*
> (funcall *fn*)
((7) 3)
> (funcall *fn*)
((7) 3)
There's no fundamental reason it couldn't have worked that way in Python. (I understand that changing the language so it worked that way now would likely break some code.)
EDIT: fixed formatting.
http://stackoverflow.com/questions/1651154/why-are-default-a...
The code that evaluates the default expression doesn't need to be in a separate function, either, so the argument that calling that function is too expensive also doesn't hold water.
I just tried a test in SBCL:
(defun foo1 (x) x)
(defun test1 (n) (dotimes (i n) (foo1 (cons nil nil))))
(time (test1 100000000))
=> 4.4 sec, or 44ns / iteration
(defun foo2 (&optional (x (cons nil nil))) x)
(defun test2 (n) (dotimes (i n) (foo2)))
(time (test2 100000000))
=> 4.1 sec, or 41ns / iteration
Look, no language is perfect -- not even Common Lisp :-) I think users are better served when design flaws in a language are acknowledged without defensiveness than when bogus justifications are offered.
I don't agree that this is a design flaw. As I recall it bit me once as a beginner, and never again in over a decade of using python, and as a lisp hacker you know you don't design a language for beginners. :-)
The equivalent Python would be something like this:
def function():
x = 3
def internal(x, foo=[]):
foo.append([7])
foo.append(x)
return foo
return internal(x)
print function()
print function()
[[7], 3]
[[7], 3]You've still got that &optional argument though. I don't see a huge amount of difference from a semantic point of view between that and the Python version though (ie. if x == None: ...).
fn = lambda y=[y]: y.push(7); return y
(The introduction of the variable x into the example is not important for the behavior of default arguments, however, it is important for a separate issue. I've stripped it out here.)