[Python-ideas] fixing mutable default argument values
jcarlson at uci.edu
Mon Jan 22 01:49:51 CET 2007
Chris Rebert <cvrebert at gmail.com> wrote:
> Josiah Carlson wrote:
> > As provided by Calvin Spealman, the above can be fixed with:
> > def popo(x=None):
> > x = x if x is not None else 
> > x.append(666)
> > print x
> > I would also mention that forcing users to learn about mutable arguments
> > and procedural programming is not a bad thing. Learning the "gotcha"
> > of mutable default arguments is a very useful lesson, and to remove that
> > lesson, I believe, wouldn't necessarily help new users to Python, or new
> > programmers in general.
> > - Josiah
Maybe you are taking me a bit too seriously, but hopefully this will add
some levity; I'm a poo-poo head. Moving on...
> First, your 'fix' misses the point: though the proposed feature isn't
> necessary, and code can be written without using it, it allows mutable
> default argument values to be expressed more clearly and succinctly than
> the idiom your 'fix' uses.
As I stated, it wasn't my fix. And using previously existing syntax
that adds 1 line to a function to support a particular desired result, I
think, is perfectly reasonable. Had the conditional syntax been
available for the last decade, those "gotchas" pages would have said
"mutable default arguments are tricky, always use the following, and it
will probably be the right thing" and moved on.
> Second, Python isn't (inherently) about
> teaching new programmers about programming, and what is good for newbies
> isn't necessarily good for experienced programmers.
Indeed, and what *may* be good for *certain* experienced programmers,
may not be good for other experienced programmers, or for the language
in general. And personally, I am not sure that I could be convinced
that a syntax to support what can be emulated by a single line is even
worthy of addition. In the case of decorators, or even the py3k support
for argument annotation, there are certain operations that can be made
*significantly* easier. In this case, I'm not convinced that the extra
syntax baggage is worthwhile.
Nevermind that it would be one more incompatible syntax that would make
it difficult to write for 2.5/2.6 and 3.x .
More information about the Python-ideas