On Mon, 20 Jun 2022 at 21:19, Steven D'Aprano <steve@pearwood.info> wrote:
(4) The guarantee that a late-bound default WILL be executed at function call time, can be useful, even essential (it could be time-dependent or it could depend on the values - default or otherwise - of other parameters whose values might be changed in the function body).
Okay. But a generalised lazy evaluation mechanism can be used to implement PEP 671 style evaluation.
Let me see if I can give a good analogy... generalised lazy evaluation is like having a car that can drive anywhere there is a road, at any time of the day or night. Late-bound defaults is like having a car that can only drive to the local mall and back, and only on Thursdays.
That's okay if you want to drive to the local mall on Thursdays, but if you could only have one option, which would be more useful?
Nice analogy. It doesn't hold up. Consider this function: def f(stuff, max=>len(stuff)): stuff.append(1) print(max) f([1,2,3]) How would you use lazy evaluation to *guarantee* the behaviour here? The only way I can imagine doing it is basically the same as I'm doing: that late-bound argument defaults *have special syntax and meaning to the compiler*. If they were implemented with some sort of lazy evaluation object, they would need (a) access to the execution context, so you can't just use a function; (b) guaranteed evaluation on function entry, regardless of when - if ever - it gets referred to; and (c) the ability to put it in the function header. The only one of those that overlaps with lazy evaluation is (c). Please stop arguing this point. It is a false analogy and until you can demonstrate *with code* that there is value in doing it, it is a massive red herring. Even if Python does later on grow a generalized lazy evaluation feature, it will only change the *implementation* of late-bound argument defaults, not their specification. ChrisA