Bizarre behavior with mutable default arguments

bukzor workitharder at gmail.com
Tue Jan 1 12:00:09 EST 2008


On Dec 31 2007, 1:30 pm, "Chris Mellon" <arka... at gmail.com> wrote:
> On Dec 31, 2007 2:08 PM, Odalrick <odalr... 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.

I'm confused by what you mean by 'early binding'. Can you give a quick-
n-dirty example?

Thanks,
--Buck



More information about the Python-list mailing list