Default Value

[88888 Dihedral]

rusi於 2013年6月21日星期五UTC+8上午1時12分01秒寫道：
> 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

Well, that was the story of the expensive memory era.the 
In 198X -2000 the auto GC of LISP was beaten 
by practical engineers using C, C++, PASCAL, and object pascal.

But now it is different in 201X.