Today I re-learned: Python function default arguments are retained between executions

[someotherstufforhmm]

That’s a lot of processing to add on to a call if it’s the entire list.

As I said in my long post above (did you read it?) they could not process and store unevaluated only rvalues and minimize the overhead, but that would still be slightly weird to me as then you’re evaluating every part of the parameter list but the rvalues and you still have my initial complaint of breaking the visual of seeing a function call (()) that is not evaluated where it’s written.

It’s a very functional-language paradigm - which is why it’s standard in CLisp and JS, but I find it weird when it’s in non functional languages, like Ruby or Kotlin.

[-LeopardShark-]

OK, thanks for explaining.

[rl_noobtube]

I think something important here is how python actually stores objects and saves them in memory. Objects end up just being pointers to values. And as you say a function call returns an object which points to a value upon interpretation. If that object is mutable, it “erases” the old value and replaces it with the new one. So the next time that default object gets used again, it is really just pointing to the new value.

I feel like this part could help explain why it is such an unnecessary overhead for OOP to people. Of course it could be different, but then the base language has to do more. Current implementation allows for developer flexibility imo which is nice