On Thursday, June 20, 2013 7:57:06 AM UTC-5, rusi wrote: > Every language has gotchas. This is one of python's.
So are we purposely injecting illogic into our language just to be part of some "cool crowd" of programming languages with gotchas. "You thought intuitiveness was a virtue? Haha, we gotcha!" Or maybe this is reminiscent of the fraternity hazing rituals of days gone by: *POP* "Thank you Sir, may i have another?" > 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. Once you cross the > noob stage you can check that its a standard gotcha: Just > run a search for 'python gotcha default []' > > 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 Your attempting to excuse an inexcusable language flaw by pointing out that the effects of the flaw can be avoided by using a workaround. And, to add insult to injury, you provide no good reason for the flaw to exist: "Just do x, y, and z and shut up. Yes we made a mistake but we are not about to admit our mistake and the onerous will be on all the noobs to re-invent the workaround each time" To me that is unacceptable. > Heres a correction suggestion: [...] Here's Terry Reedy's > nicely explaining the 'why-of-the-how' : [...] FWIW here > is a conceptual/philosophical explanation of your > confusion: There are 2 fundamental ways for approaching > the programming task -- functional and imperative. All these "explanations" ignore a fundamental fact about subroutines[1]. A call to a subroutine should exists as a unique transaction within the entire program. It is expected to optionally take inputs, and optionally return an output (depending on the definition). When the subroutine is completed, all inputs and local variables are expected to be destroyed. If the programmer wants a return value, he need simply ask. Data persistence is not a function of subroutines! Finally, a subroutine should never have side effects UNLESS the programmer explicitly ask for a side effect. However, the Python flaw of allowing mutable sequence arguments to persist between successive calls of a subroutine is breaking the entire definition of a subroutine, and for what noble purpose i ask? What purpose is SO important that you change a well established interface in a totally unintuitive manner? If your answer is that recursion is easier, then i say that is foolish because a programmer can keep a reference to a mutable sequence OUTSIDE the subroutine and you can save the "gotchas" for Guido's next birthday party. [1]: http://en.wikipedia.org/wiki/Subroutine -- http://mail.python.org/mailman/listinfo/python-list