...you know, assuming it wouldn't break existing code.
It will. Python's default argument strategy has been in use for 20 years.
Some code will rely on it. I know mine does.
There are two strategies for dealing with default arguments that I know
of: early binding and late binding. Python has early binding: the default
argument is evaluated once, when the function is created. Late binding
means the default argument is always re-evaluated each time it is needed.
Both strategies are reasonable choices. Both have advantages and
disadvantages. Both have use-cases, and both lead to confusion when the
user expects one but gets the other. If you think changing from early to
late binding will completely eliminate the default argument "gotcha", you
haven't thought things through -- at best you might reduce the number of
complaints, but only at the cost of shifting them from one set of use-
cases to another.
Early binding is simple to implement and simple to explain: when you
define a function, the default value is evaluated once, and the result
stored to be used whenever it is needed. The disadvantage is that it can
lead to unexpected results for mutable arguments.
Late binding is also simple to explain, but a little harder to implement.
The function needs to store the default value as a piece of code (an
expression) which can be re-evaluated as often as needed, not an object.
The disadvantage of late binding is that since the expression is live, it
needs to be calculated each time, even if it turns out to be the same
result. But there's no guarantee that it will return the same result each
time: consider a default value like x=time.time(), which will return a
different value each time it is called; or one like x=a+b, which will
vary if either a or b are changed. Or will fail altogether if either a or
b are deleted. This will surprise some people some of the time and lead
to demands that Python "fix" the "obviously buggy" default argument
gotcha.
If a language only offers one, I maintain it should offer early binding
(the status quo). Why? Because it is more elegant to fake late binding in
an early binding language than vice versa.
To fake late binding in a language with early binding, use a sentinel
value and put the default value inside the body of the function:
  def func(x, y=None):
    if y is None:
      y = []
    ...
All the important parts of the function are in one place, namely inside
the function.
To fake early binding when the language provides late binding, you still
use a sentinel value, but the initialization code creating the default
value is outside the body of the function, usually in a global variable:
  _DEFAULT_Y = []  # Private constant, don't touch.
  def func(x, y=None):
    if y is None:
      y = _DEFAULT_Y
    ...
This separates parts of the code that should be together, and relies on a
global, with all the disadvantages that implies.
