Default Value

[Rick Johnson]

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