Optional parameter object re-used when instantiating multiple objects

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Fri Nov 21 05:09:07 CET 2008

On Wed, 19 Nov 2008 11:26:54 -0800, George Sakkis wrote:

> On Nov 19, 1:05 pm, Dennis Lee Bieber <wlfr... at ix.netcom.com> wrote:
>> On Wed, 19 Nov 2008 05:41:57 -0800 (PST), Rick Giuly
>> <rgiuly.gr... at yahoo.com> declaimed the following in comp.lang.python:
>> > (By "better" I mean that over many years of time programmers will be
>> > more productive because the language will be learned a bit faster
>> > with a fewer surprises - and still retain its power.)
>>         Your opinion... I'm sure there are some libraries out there
>>         that
>> rely upon the current behavior
> That's a straw man; of course they rely on it since they can. The same
> would be even more true if the opposite behavior was selected from the
> beginning, many more libraries would rely on it instead of (ab)using
> None as default.

"Many more"? You're guessing. By memory, most uses in the standard 
library for default values either use immutables (strings or ints), in 
which case rebinding the default at runtime is irrelevant, or are using 
None to trigger special behaviour. (Please feel free to go through the 
std lib and verify my feeble memories.) The *specific* gotcha people are 
complaining about only affects a tiny proportion of default values: in 
practice, it is almost always either [] or {}.

It seems a waste to have Python pay the cost of re-evaluating all those 
default=0 and default=None calls just to satisfy a small proportion of 
users whose intuition about Python's behaviour happens to be wrong. Since 
that intuition has real costs and the current behaviour has real 
benefits, people should just learn the Python way.

(I'm sympathetic for requests for syntactic sugar to get runtime 
evaluation of defaults. I'm not sympathetic at all for requests to change 
the default behaviour.)

> That's the only argument that may worth some merit. It's interesting
> though that C++, a language much more obsessed with performance, picks
> the runtime semantics:

You're not going to hold C++ up as a shining beacon of the right way to 
do things, are you?


More information about the Python-list mailing list