spir writes:
Especially, why should immutable defaults be OK, and mutable ones be wrong and replaced with explicit value at call time?
"Although practicality beats purity." Consider a wrapper for something like Berkeley DB which has a plethora of options for creating external objects, but which most users are not going to care about. It makes sense for those options to be optional. Otherwise people will be writing def create_db(path): """Create a DB with all default options at `path`.""" create_db_with_a_plethora_of_options(path,a,b,c,d,e,f,g,h,i,j,k,l,m) def create_db_with_nondefault_indexing(path,indexer): """Create a DB with `indexer`, otherwise default options, at `path`.""" create_db_with_a_plethora_of_options(path,indexer,b,c,d,e,f,g,h,i,j,k,l,m) etc, etc, ad nauseum. No, thank you!
I would rather require the contrary, namely that static vars should not be messed up with default args. This is not only confusion in code, but also design flaw. here's how I see it various possibilities (with some amount of exageration ;-):
def f(arg, lst=[]): # !!! lst is no default arg, !!! # !!! it's a static var instead !!! # !!! that will be updated in code !!! <do things>
def f(arg): <do things> f.lst = [] # init static var
Don't generators do the right thing here? def f(arg): lst = [] while True: <do things> yield None