4 ms·

Expensive, though. http://stackoverflow.com/questions/1651154/why-are-default-arguments-evaluated-at-definition-time-in-python http://stackoverflow.com/questio

• ScottBurson 14y ago
  Surely not. The implementation already has to check that the number of provided arguments is valid. The decision of whether to evaluate the default expression can be part of that. 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 The version with the optional parameter is actually slightly faster, which completely blows a hole in the performance argument. 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.
  • Estragon 14y ago
    You're assuming that the function-calling overhead is the same in python as in CL. I don't think that's the case, and it definitely wasn't at the start. 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. :-)