On Sat, Dec 04, 2021 at 06:11:08PM +0000, Barry Scott wrote:
There are many possible implementation of the late bound idea that could create an object/default expression. But is it reasonable to bother with that added complexity/maintenance burden for a first implementation.
I don't think we can conclude that factoring out the late-bound defaults into their own routines is "added complexity/maintenance burden". Usually, factoring stand-alone code into its own routines *reduces* the maintenance burden, it doesn't increase it. You can test chunks of code in isolation. You can refactor it. It is easier to analyse and understand. The ability to introspect code is not a "burden", it is a feature that reduces the difficulty of testing and maintaining code. That's why we have functions in the first place, instead of having one giant ball of mud. https://exceptionnotfound.net/big-ball-of-mud-the-daily-software-anti-patter... Chris wants to throw the late-bound defaults into the body of the function because that's what we are currently forced to do to emulate late-bound defaults. But we are designing the feature from scratch, and we shouldn't be bound by the limitations of the existing idiom. Encapsulation is good. Putting late-bound expressions in their own function so that they can be tested is a good thing, not a problem to be avoided. Most of us have, from time to time, already moved the late bound default into its own function just to make it easy to test in isolation: def func(arg=None): if arg is None: arg = _implementation() # and now handle arg With my strategy, we get that isolation for almost for free. There is no extra effort needed on the programmer's side, no new name or top-level function needed. Will people take advantage of it? Of course people won't bother if the default is `[]` but beyond a certain level of complexity, people will want to test the default expressions in isolation, to be sure that it does the right thing. -- Steve