[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
cvrebert at gmail.com
Tue Jan 30 08:25:58 CET 2007
Josiah Carlson wrote:
> 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
No, it's just that why use several different decorators when a slight
change in semantics renders them all obsolete? Why have to use a
decorator/lambda/conditional and remember when to use which? I'm trying
to generalize the pattern of "reevaluate/copy default values each time
they're required" into new behavior for default arguments. Indeed, as I
stated in another email (no idea which one, there's been too many), I
wholeheartedly support adding some of those decorators to the standard
library should my PEP get rejected.
> 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
> def append_10(lst=):
> return lst
> I would presumably change it to...
> def append_10(lst=None):
> if lst is None: lst = 
> return 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).
Nowhere has it been proposed to forbid passing None as an argument. The
basic core of the proposal is to have Python compile the code such that
the boilerplate is either removed entirely (if the new semantics are the
default) by no longer being necessary, or dramatically shortened via the
addition of a new keyword (which would indicate the new semantics). Yes,
you can manually transform your code to use the idiom you mention. But
why should you have to? Why not have Python do the heavy-lifting for you?
As stated in the "Reference Implementation" section of the PEP, the
'translation' provided is not intended to be a literal translation of
the code at compile-time, but rather explain how Python's
argument-handling machinery should be changed. The 'translation' looks
similar to the existing idiom because that's what it aims to replace.
But note that it's *Python* that's doing this 'translation', not the
programmer! That's the gain! The programmer no longer needs to write the
> 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.
I'm not here to argue that people shouldn't be made to understand the
difference between mutable and immutable values. They definitely should
know the difference. I'm just advocating a language change to make
certain kinds of functions less verbose. If you're worried about losing
this 'teaching tool' (which another respondent was worried about), it
will still exist in the form of:
x = [*4]*4
x = 7
x == 7 #TRUE!
- Chris Rebert
More information about the Python-ideas