Bizarre method keyword-arg bug.

[Steven D'Aprano]

On Wed, 20 Aug 2008 15:58:44 -0400, Robert Brown wrote:

> Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> 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