On Jun 20, 12:38 am, Rick Johnson <rantingrickjohn...@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 -- http://mail.python.org/mailman/listinfo/python-list
