Bizarre behavior with mutable default arguments

[Chris Mellon]

On Dec 31, 2007 2:08 PM, Odalrick <odalrick at hotmail.com> wrote:
> On 31 Dec, 18:22, Arnaud Delobelle <arno... at googlemail.com> wrote:
> > On Dec 31, 10:58 am, Odalrick <odalr... at hotmail.com> wrote:
> >
> > > On 30 Dec, 17:26, George Sakkis <george.sak... at gmail.com> wrote:
> >
> > > > On Dec 29, 9:14 pm, bukzor <workithar... at gmail.com> wrote:
> >
> > > > > Here's the answer to the question:http://www.python.org/doc/faq/general/#why-are-default-values-shared-...
> >
> > > > > It looks like Guido disagrees with me, so the discussion is closed.
> >
> > > > Note that the FAQ mainly explains *what* happens, not *why* was this
> > > > decision taken. Although it shows an example where "this feature can
> > > > be useful", it's neither the only way to do it nor is memoization as
> > > > common as wanting fresh default arguments on every call.
> >
> > > I'm surprised noone has said anything about the why of default
> > > mutables. I think it is becasue it isn't easy to do it an other way.
> >
> > [...]
> >
> > There is an easy enough way: evaluate default values when the function
> > is called rather than when it is defined.  This behaviour comes with
> > its own caveats as well I imagine, and it's not 'as easy' to implement
> > as the current one.
> >
>
> Adding overhead to *all* function calls, even the ones without mutable
> defaults. That doesn't sound like an attractive tradeoff.
>

And also removing the only way you can currently do early binding in
Python. I agree that it's a gotcha, but unless someone comes up with
an answer to the following questions, I'll stick with the status quo
(Note that this is not blind Python group-think as a previous poster
implied, but a pragmatic decision that this is the most practical
solution):

a) If we don't evaluate default arguments at function compilation,
when do we do it?
b) If you do it at call time, how do you implement early binding?
c) If you want to introduce new syntax for the current behavior, what
is it and can you justify it?
d) What are the performance implications of your proposal versus the
current behavior?

Note that the desired behavior can be implemented under the current
behavior, at the expense of verbosity - using factories and sentinel
values as the default arguments, and then expanding them in the
function. It's not possible to implement the current behavior of
early-bound arguments if default arguments are evaluated with every
call. This alone is a good reason to keep the current behavior until
someone actually has a good alternative that covers the current use
cases and isn't just upset by the behavior.