Empty list as default parameter

[Bengt Richter]

On 22 Nov 2003 19:05:58 -0800, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:

>bokr at oz.net (Bengt Richter) writes:
>> Yes. The bindings of default values for call args are evaluated at
>> define-time, in the context of the definition, not at execution
>> time, when the function is called.
>
>That's always seemed like a source of bugs to me, and ugly workarounds
>for the bugs.  Is there any corresponding disadvantage to eval'ing the
>defaults at runtime as is done in other languages?
What languages are you thinking of? A concrete example for comparison would
clarify things. Would you have default expressions effectively passed in as
the bodies of lambdas (which might mean creating closures, depending on what was
referenced) and then executed to create the local bindings prior to the first line in
a function or method? It would certainly be inefficient for all the cases where you
just wanted a static default (unless you special cased those to work as now -- but
remember, only bare names and constant literals could be special cased that way. An
expression like os.RD_ONLY (yes that is an expression!) would have to be passed as
lambda: os.RDONLY). So you'd have to counter that by making bare-name bindings prior
to calls, like tmp_mode=os.RD_ONLY; os.open('foo.txt', tmp_mode); #etc

I expect the use cases balance favor the current methodology. A cursory grep though
defs of /lib/*py shows no defaults at all to be the majority (>80%?) and of the defs
with '=' in the same line (983 of 5443), most seem to be =None or =<some int> or =<some string>
to the tiring eyeball. I didn't process it.

Regards,
Bengt Richter