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

[Chris Rebert]

Collin Winter wrote:
> On 1/29/07, Chris Rebert <cvrebert at gmail.com> wrote:
>> Collin Winter wrote:
>> > On 1/28/07, Chris Rebert <cvrebert at 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.
> 
> Tomer wasn't proposing that any of those decorators be included in the
> standard library. Those cases where one of decorators isn't sufficient
> as written? Modify it, use it in your code, post it to the cookbook.
> Not every n-line function should be turned into syntax.

Right, but for something used so frequently, should you really have to 
look through N decorator recipes, figure out which one you want, and 
then modify it, as opposed to a change in semantics that obviates the 
need for such decorators altogether?

>> 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).
> 
> You can't do that as things are, so that's not a strike against the
> decorator-based approach.

Valid point. It's actually more pro-reevaluation than it is anti-decorator.

>> > 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 you work on this, think about how you'll explain the new semantics
> in the documentation. Rewriting http://docs.python.org/ref/calls.html
> and http://docs.python.org/ref/function.html -- paying particular
> attention to paragraphs 2-5 in the former -- would be a good start.

Sweet! Thanks for the link.

- Chris Rebert