[Python-ideas] proto-PEP: Fixing Non-constant Default Arguments
collinw at gmail.com
Tue Jan 30 06:22:10 CET 2007
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  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.
> 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
> > 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 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.
More information about the Python-ideas