On Tue, 30 Jan 2007 18:16:03 +0100, Josiah Carlson firstname.lastname@example.org wrote:
Chris Rebert email@example.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
not mutable. So I don't buy the whole "but then None would no longer
valid argument to pass" bull that was offered as a reason why the
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.