[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
jcarlson at uci.edu
Tue Jan 30 06:50:01 CET 2007
Chris Rebert <cvrebert at gmail.com> wrote:
> Collin Winter wrote:
> > On 1/28/07, Chris Rebert <cvrebert at gmail.com> wrote:
> > Syntax changes are a huge stick to wield against such a small problem.
> > I realize the boilerplate is annoying, but Tomer has pointed out a
> > number of decorator-based solutions  that could easily be adapted
> > to any unusual needs you have.
> One of his decorators assumes that the default value merely needs to be
> copied across calls. However, as the PEP says, there are cases where
> this isn't sufficient or just doesn't work. His second decorator
> involves using lambdas (ick!),
Using the features of a language to attempt to compensate for that same
language's (argued) shortcomings are a valid _and encouraged_ approach.
Your poo-pooing of Python conditionals, decorators, and lambdas to solve
this particular problem, to me, seems like you want a *particular
I don't see a problem with the current default argument semantics. Why?
Because in the case where I would want to receive a mutable parameter,
like in the case below that wouldn't work with Python's standard
I would presumably change it to...
if lst is None: lst = 
Or some variant thereof. Now, here's the thing; if I want a mutable
argument, then None is a nonsensical value to pass, generally, as it is
not mutable. So I don't buy the whole "but then None would no longer be a
valid argument to pass" bull that was offered as a reason why the above
isn't a reasonable translation (I can't remember who offered it).
I'm also not convinced by either of the 3 pages that talk about Python
"gotchas". You get bitten by it, you learn it, understand it, and move
on. If they can't figure it out, I'm not sure I want them writing
Python software anyways; I certainly wouldn't want them to work on any
of the Python software I work on and use.
More information about the Python-ideas