Default Value

[rusi]

On Jun 20, 12:38 am, Rick Johnson <rantingrickjohn... at gmail.com>
wrote:
> On Wednesday, June 19, 2013 2:17:35 PM UTC-5, Ahmed Abdulshafy wrote:
> > I'm reading the Python.org tutorial right now, and I found
> > this part rather strange and incomprehensible to me>
>
> > Important warning: The default value is evaluated only
> > once. This makes a difference when the default is a
> > mutable object such as a list, dictionary, or instances of
> > most classes
>
> > def f(a, L=[]):
> >     L.append(a)
> >     return L
>
> > print(f(1))
> > print(f(2))
> > print(f(3))
>
> > This will print
>
> > [1]
> > [1, 2]
> > [1, 2, 3]
>
> > How the list is retained between successive calls? And
> > why?
>
> By the evil hands of an illogical consistency.
>
> Have you ever heard the old adage: "The road to hell is
> paved in good intentions"? Well, apparently the original
> designers of the language called in sick the day that class
> was taught. It's unfortunate because the same functionality
> that this "intention" claims to solve can be reproduced
> easily, and in a less astonishing manner, by the programmer
> himself.
>
>  http://en.wikipedia.org/wiki/Principle_of_least_astonishment


Every language has gotchas. This is one of python's.

If you are a beginning python programmer, really the best answer is:
Just dont do it!  Dont do what? Dont use mutable arguments as function
defaults.
And when you feel that you need to, use Steven's trick: use a
immutable indicator 'None' for the mutable [].

Once you cross the noob stage you can check that its a standard
gotcha: Just run a search for 'python gotcha default []'

Its even been discussed repeatedly on the python-ideas list
Heres a correction suggestion: http://mail.python.org/pipermail/python-ideas/2007-January/000073.html
Here's Terry Reedy's nicely explaining the 'why-of-the-how' :
http://mail.python.org/pipermail/python-ideas/2009-May/004680.html

FWIW here is a conceptual/philosophical explanation of your confusion:

There are 2 fundamental ways for approaching the programming task --
functional and imperative.
In FP, the primary requirement is that the behavior of a function
should be entirely determinable by its arguments.
In Imp. P, computation proceeds by changing state.

Now from the time of Backus turing award http://amturing.acm.org/award_winners/backus_0703524.cfm
it is known that the two philosophies are mutually incompatible.  Now
python is in a rather unique position in this respect: it supports
many of the features of modern FPLs and one can almost do functional
programming in it.  In a few cases the imperative/Object-based
internals leak out, this is one of those cases.

That such leakage will occasionally happen see:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

And you've had a little excess of the FP koolaid read :
http://blog.languager.org/2012/08/functional-programming-philosophical.html