Collin Winter wrote:
On 1/28/07, Chris Rebert cvrebert@gmail.com 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 [1] 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!), and doesn't allow you to refer to other arguments in determining the default value (think 'self' as a hint for how this could be useful). Also, I just think it's plain nicer/prettier if decorators don't have to be used for this.
Also, you haven't talked at all about how all this might be accomplished. You say
Given these semantics, it makes more sense to refer to default argument expressions rather than default argument values, as the expression is re-evaluated at each call, rather than just once at definition-time.
but how do you intend to capture these "default argument expressions"? Emit additional bytecode for functions making use of these special default arguments?
The "Reference Implementation" section of the PEP discusses this. I don't personally know Python's internals, but I imagine this proposal would just change how default arguments are compiled and might entail some changes to the interpreter's argument-processing machinery. As Jan Kanis pointed out, the PEP does need to elaborate on exactly what kind of variables the default arguments use/are. I'm working on revising this in the next draft.
- Chris Rebert