Home Original page

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

Collin Winter collinw at gmail.com
Tue Jan 30 05:36:51 CET 2007 
On 1/28/07, Chris Rebert <cvrebert at gmail.com> wrote:
> Rationale
[snip]
> There was some concern over the possible performance
> hit this could cause, and whether there should be new syntax so that
> code could use the existing semantics for performance reasons.  Some of
> the proposed syntaxes were:
>
>      def foo(bar=<baz>):
>          #code
>
>      def foo(bar=new baz):
>          #code
>
>      def foo(bar=fresh baz):
>          #code
>
>      def foo(bar=separate baz):
>          #code
>
>      def foo(bar=another baz):
>          #code
>
>      def foo(bar=unique baz):
>          #code
>
> where the new keyword (or angle brackets) would indicate that the
> parameter's default argument should use the new semantics.

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.

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?

Collin Winter
More information about the Python-ideas mailing list