Default Value

[rusi]

You know Rick, you are good at python, you are better at polemics.
If only you would cut the crap I would (be able to) agree with you.
See below

On Jun 20, 7:49 pm, Rick Johnson <rantingrickjohn... at gmail.com> wrote:
> 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!"


Python (and all the other 'cool' languages) dont have gotchas because
someone malevolently put them there.
In most cases, the problem is seen too late and the cost of changing
entrenched code too great.
Or the problem is clear, the solution is not etc etc.

>
> 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


You are saying in different language what I said: Functional
programming is a good idea, imperative programming is a bad idea.
>From the invention of subroutines (ie 50 years) PL designers are
hearing this truth but somehow or other fail to listen; for more
details see http://blog.languager.org/2012/11/imperative-programming-lessons-not.html