Empty list as default parameter
bokr at oz.net
Sun Nov 23 17:33:37 CET 2003
On 22 Nov 2003 22:06:03 -0800, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
>bokr at oz.net (Bengt Richter) writes:
>> >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.
>Common Lisp is the most obvious one.
You are referring to initforms, I assume. I wonder how often macros are used
IRL to defeat the deferral and plug in pre-computed static default values that
the compiler can't infer its way to at compile time?
>> 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 ...
>The compiler can do the obvious things to make efficient code in the
>> (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
>Rather than have the programmer go through such contortions it's better
>fix the compiler to generate the obvious code inline, and then rely
>on the compiler to get these things right.
I wasn't really advocating programmer contortions ;-)
But the trouble is that the compiler can't guess what you _mean_, except
for the obvious cases of bare names and constant literals, so otherwise you have
to code explicitly in any case. E.g., is it obvious that getattr(os, 'RD_ONLY')
should be done at call time or optimized away to def time in os.open('foo.txt', os.RD_ONLY) ?
I don't think you can optimize it away without telling the compiler one way or another,
or changing the dynamic nature of the language.
In any case it would be a semantic change, and I'd hate to have the job of finding breakage ;-)
More information about the Python-list