Bizarre behavior with mutable default arguments

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


On Jan 1, 9:00 am, bukzor <workithar... at gmail.com> wrote:
> 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

Is an 'early bound' variable synonymous with a 'static' variable (in
C)?



More information about the Python-list mailing list