Bizarre method keyword-arg bug.

[Fredrik Lundh]

Re: Bizarre method keyword-arg bug.

Steven D'Aprano wrote:

>It doesn't help that the solution to get the expected behavior involves
>adding boiler-plate code all over.

>
Expected by who?

Blub programmers.

</F>

[Fredrik Lundh]

Re: Bizarre method keyword-arg bug.

Robert Brown wrote:

You may find the above surprising, but Common Lisp users expect the default
argument expression to be evaluated anew when need by a function call:

I find the Lisp approach more reasonable. Also, an argument based on
performance for Python's current behavior seems dubious, given the
language's other performance robbing design choices.

well, I'd say an argument based on "Common Lisp users" is a lot more
dubious ;-)

(and some of us are actually capable of writing pretty fast code in
Python. slowing the language down (or crippling it) because some blub
programmers screams "bug!" instead of looking things up in the handbook
when they stumble upon something they haven't seen before doesn't strike
me as a good use of anyone's time.)

</F>

[Robert Brown]

Re: Bizarre method keyword-arg bug.

Fredrik Lundh <fredrik@python ware.comwrites:

Robert Brown wrote:

>You may find the above surprising, but Common Lisp users expect the
>default argument expression to be evaluated anew when needed by a
>function call:

>
well, I'd say an argument based on "Common Lisp users" is a lot more
dubious ;-)

Actually, it's really not dubious. Because Lisp is extensible, Lisp *users*
have evolved the language considerably over the years. It's an excellent
place to look for alternative design ideas. For instance, Lisp users
experimented with several ways (LOOPS, Flavors, etc.) of supporting the
object oriented style of programming before CLOS became part of the Common
Lisp standard. If you're designing a language feature, it's often the case
that Lisp users have tried several alternatives over the last few decades
and have decided what works best, for them of course.

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.
We're talking about a language used to implement operating systems --
performance is always a consideration.

[Steven D'Aprano]

Re: Bizarre method keyword-arg bug.

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.


--
Steven

[Robert Brown]

Re: Bizarre method keyword-arg bug.

Steven D'Aprano <steve@REMOVE-THIS-cybersource.com .auwrites:

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.

[Steven D'Aprano]

Re: Bizarre method keyword-arg bug.

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

Steven D'Aprano <steve@REMOVE-THIS-cybersource.com .auwrites:

>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