Chris Rebert email@example.com wrote:
Collin Winter wrote:
On 1/28/07, Chris Rebert firstname.lastname@example.org 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 solution*.
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).
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.