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...@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. -- http://mail.python.org/mailman/listinfo/python-list
