On Mon, 20 Jun 2022 at 21:19, Steven D'Aprano <st...@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 _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2KA7SZAEWNH55HNEMK6H3UHWC5TZTS2Y/ Code of Conduct: http://python.org/psf/codeofconduct/