Bizarre method keyword-arg bug.
steve at REMOVE-THIS-cybersource.com.au
Thu Aug 21 07:49:02 CEST 2008
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
But if you want a simple example, consider this function definition:
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
Frankly, I can't see how any language, including Lisp, could possibly
avoid that runtime cost.
More information about the Python-list