[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments

[Chris Rebert]

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
> solution*.

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
> semantics...
> 
>     def append_10(lst=[]):
>         lst.append(10)
>         return lst
> 
> I would presumably change it to...
> 
>     def append_10(lst=None):
>         if lst is None: lst = []
>         lst.append(10)
>         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 
boilerplate.

> 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 = [[0]*4]*4
x[3][1] = 7
x[0][1] == 7 #TRUE!

- Chris Rebert