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

[Jan Kanis]

On Tue, 30 Jan 2007 18:16:03 +0100, Josiah Carlson <jcarlson at uci.edu>  
wrote:
>
> Chris Rebert <cvrebert at gmail.com> wrote:
>>
>> > 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.
>
> And I never claimed as much.  There was a previous post by someone (I
> can't remember who offered it), saying that replacing 'lst=[]' with
> 'lst=None' would make it so that a user couldn't signal *something
> special* with a 'None' argument.  I was trying to get across that such
> reasoning doesn't make sense in this particular context.

The above example code was mine. I was just trying to explain that the  
proposed semantics should not mistake a caller-provided argument value of  
None for a no-argument-provided situation and evaluate the default  
expression. If the proposal were to be implemented naively by literally  
rewriting the python code in the way that I used to explain the proposal  
and compiling the rewritten code, this bug could happen.

- Jan