It's pretty odd behavior, yeah. It's easy to work around (set the default to None and then set the actual default in the function body), but I don't know if I've _ever_ seen anyone want it to behave as it does now.
default = 10
def foo(x=default):
return x
default = 20
assert foo() == 10
It could also be that the default value is a more ocmplex expression, we could use a function to generate a default argument.
def foo(x=create_default(y, z))
And yes it is used, for example the fastapi Dependency Injection system has been build quite cleverly using the ability to construct default values
https://fastapi.tiangolo.com/tutorial/query-params-str-valid...
Yes it is one of those things you just have to learn, but there are tons of stuff like that in most programming languages.
The default isn't a literal value when it is [], by the way.
If [] were a literal, then this would not be safe or correct:
def fun():
local = []
local.append(3)
Python just calls that a literal because it looks like one.
Looking is being, in Python. Except for all the pitfalls.
wildly_changing_variable = random_initializer();
stable_snapshot = wildly_changing_variable
def foo(arg = stable_snapshot):
...
def foo(arg = wildly_changing_variable)
I don't understand your "closure" comments; either way, things are being lexically closed. It's a question of when evaluation takes place, not in what scope or under what scoping discipline.
In fact, Python's treatment requires the implementation to have a hidden storage that is closed over; the equivalent of my stable_snapshot variable has to be maintained by the implementation. The definition-time evaluation has to stash the value somewhere, so to that it can use that one and not the current.