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/

Reply via email to