Terry Reedy writes:
Given how often this issue is resuscitated, I am will consider raising my personal vote from -1 to -0.
Do focus on practical issues, properly qualified statements, and how a proposal would improve Python.
One thing I would like to see addressed is use-cases where the *calling* syntax *should* use default arguments. In the case of the original example, the empty list, I think that requiring the argument, and simply writing "foo()" instead of "foo()" is better, on two counts: EIBTI, and TOOWTDI. And it's certainly not an expensive adjustment.
In a more complicated case, it seems to me that defining (and naming) a separate function would often be preferable to defining a complicated default, or explicitly calling a function in the actual argument. Ie, rather than
def consume_integers(ints=fibonacci_generator()): for i in ints: # suite and termination condition
def consume_integers(ints): for i in ints: # suite and termination condition
def consume_fibonacci(): consume_integers(fibonacci_generator())
def consume_integers_internal(ints): for i in ints: # suite and termination condition
def consume_integers(): consume_integers_internal(fibonacci_generator())
depending on how frequent or intuitive the "default" Fibonacci sequence is? IMO, for both above use-cases EIBTI applies as an argument that those are preferable to a complex, dynamically- evaluated default, and for the second TOOWTDI also applies.
Footnotes:  In the particular cases being advocated as support for dynamic evaluation of default arguments, not in general. It is clear to me that having defaults for rarely used option arguments is a good thing, and I think that is a sufficient justification for Python to support default arguments.