Bizarre method keyword-arg bug.

[Robert Brown]

Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
> On Mon, 18 Aug 2008 03:20:11 -0700, Jasper wrote:
> "And no, the alternative /does not/ have an equivalent set of surprises 
> -- it's not like Python is unique in having default arguments."
>
> That's simply not true. I would find this behaviour very surprising, and 
> I bet you would too:
>
>>>> x = "parrot"
>>>> def foo(obj=x):
> ...     print obj
> ... 
>>>> foo()  # this is the current behaviour
> parrot
>>>> x = "shrubbery"
>>>> foo()  # but this is not
> shrubbery
>>>> del x
>>>> foo()  # nor is this
> Traceback (most recent call last):
> NameError: name 'x' is not defined

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:

    * (defvar *x* "parrot")
    *X*

    * (defun foo (&optional (obj *x*))    ;; optional arg, default is *x*
        obj)
    FOO

    * (foo)
    "parrot"

    * (setf *x* "shrubbery")
    "shrubbery"

    * (foo)
    "shrubbery"

    * (makunbound '*x*)
    *X*

    * (foo)
    debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "initial thread"
    RUNNING {10023EDE81}>:
      The variable *X* is unbound.

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.

bob