On Wed, 20 Aug 2008 15:58:44 -0400, Robert Brown wrote: > Steven D'Aprano <[EMAIL PROTECTED]> writes: >> On Wed, 20 Aug 2008 13:09:21 -0400, Robert Brown wrote: >> >>> In any case, chances are high that Lisp's way of handling default >>> arguments would have been changed had it been shown to cause >>> performance problems. >> >> But nobody is suggesting that it would cause performance problems in >> *Lisp*. It might, or it might not. Who cares? We're not talking about >> Lisp, we're talking about *Python*, and evaluating default arguments >> every time the function is called would certainly cause a performance >> hit in Python. > > Please explain why it's a performance problem for Python but not for > other languages.
Because other languages are implemented differently from Python, just as other languages are implemented differently from Lisp, C, Basic, Forth, Smalltalk, Whitespace, Ruby, PHP, Java, and quite a few others. If you mean, why is it a problem for Python but not Lisp, I'm afraid I'll have to defer to others who are more knowledgeable about the implementation than I am. All I know is that Fredrik Lundh, who has forgotten more about Python than I know, has stated: "it's done that way on purpose, of course, because evaluating a full closure for each default argument at every call would greatly hurt performance" But if you want a simple example, consider this function definition: def parrot(x=expr) Evaluating expr will take arbitrary time. If you don't believe me, consider the pathological case of x=time.sleep(10**6). The current semantics pays that cost once, when the def statement is executed, and from that point on retrieving the default value of x is almost free. Evaluating expr every time the function is called will pay that cost every time. Frankly, I can't see how any language, including Lisp, could possibly avoid that runtime cost. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
