"Is that by design" - Well, yes and no. Try to forget the specific context for the moment.

It is by design that the default parameter to a function parameter is evaluated only once, as the alternative has bad performance implications.

It is by design that when you have a reference, that modifications to that value are still available on the same reference. (That is, Python has mutable objects with a couple of immutable exceptions.) This is obviously a fairly normal choice, very basic to the language design.

Now, take these two normal things together and you get that if you make your default function parameter a mutable object, it'll be the same mutable object every time. The relevant "import this" aphorism would be "Special cases aren't special enough to break the rules."

So, is this "by design"? Well, not directly, it's a natural consequence of other aspects of the design. All languages have corner cases of one sort or another. Making this an exception would itself be a wart, after all:

      l = []
      def f(param = l): pass
      def g(param = []): pass

Shouldn't f and g have similar behavior? If you propose that the value be evaluated every time, they won't, and then people would complain about that, too.

> It is by design that the default parameter to a function parameter is evaluated only once, as the alternative has bad performance implications.

Do people actually use the results of long-running or side-effectful functions as default parameters? It seems the only time this issue comes up is when people get tripped up by mutating simple [] or {} default parameters.

I would expect a default expression to be simple and pure. If this expression should only be executed once, requiring a programmer to be explicit about the complexity wouldn't be a bad thing.

It can be a cute hack to get around the absence of static variables.

Lists have other quirks related to mutability; there are other obscure Pythonisms that use this. If you want a nice magic-free immutable container, tuples are a better bet.

I often evolve type in a single var into something more complex,

    foo = makeSomethingDifferent( foo )

And I need to catch myself when foo is a default param

Regarding the code:

  l = []
  def f(param = l): pass
  def g(param = []): pass

I would say f should be a syntax error, as languages shouldn't allow a default parameter to be an expression. If people wanted that behavour, they could write:

   def f(param =[]):
      if param==[]: param = l
      #...etc...

In Python, [] is an expression too; it is an expression that constructs an empty list and returns it.

Again, if you change this just for argument lists, you're looking at another wart.

I'm not disagreeing with you. Your logic makes sense in isolation. However, language design invariably requires this sort of tradeoff.

I was pleased to find that Ruby isn't like this. So param=[] means param=Array.new, and it gets called every single time you call the method with a parameter missing.

> So param=[] means param=Array.new, and it gets called every single time you call the method with a parameter missing.

How far down does Ruby copy? (A default value could be deep.) How does the programer specify a different level (including no copying)?

Python's rule seems bad until you try to use the alternatives outside the single case that they were designed for. Python's rule handles all cases reasonably.

It doesn't copy anything - it literally is calling "Array.new()" to generate a new array, every time one is needed.

To do it the python way, you'd have to use a global variable to store the array - which is exactly what python is doing for you. Doesn't sound so handy when its put like that, huh?

does anyone have something from the BDFL on this?