On Sat, 18 Jun 2022 at 12:36, Steven D'Aprano <st...@pearwood.info> wrote:
> I expect Chris will be annoyed at me raising this, but one way of
> implementing this would be to introduce a generalised "lazy evaluation"
> mechanism, similar to what Haskell does, rather than special-casing
> late-bound defaults. Then late-bound defaults just use the same
> mechanism, and syntax, as lazily evaluated values anywhere else.
Go ahead. Implement it. It actually is NOT sufficient, for a number of
reasons, which I have laid out in previous posts.
Generic "lazy evaluation" is sufficient to do *some* of what can be
done with late-bound argument defaults, but it is not sufficient for
everything, unless it is a nightmare that basically involves eval'ing
a text string in the surrounding context, with full ability to create
and reference any name bindings. Python does not support this concept.
> Chris may choose to reject this generalised lazy evaluation idea, but if
> so it needs to go into a Rejected Ideas section. Or he may decide that
> actually having a generalised lazy evaluation idea is *brilliant* and
> much nicer than making defaults a special case.
It's an almost completely orthogonal proposal. I used to have a
reference to it in the PEP but removed it because it was unhelpful.
> This raises another choice: should lazy defaults be evaluated before
> entering the body of the function, or at the point where the parameter
> is used? Which would be more useful?
>
> # `defer n=len(items)`
> def func(items=[], n=>len(items)):
> items.append("Hello")
> print(n)
>
> func()
That's one of the problems. Generic lazy evaluation should be
processed at some point where the parameter is used, but late-bound
defaults are evaluated as the function begins. They are orthogonal.
> Printing 1 would require a generalised lazy mechanism, but printing 0
> is independent of the mechanism. As it stands, the PEP requires 0. Which
> would be better or more useful?
Probably both. If someone wants to propose a generic deferred
evaluation feature, I would be happy to discuss it, but it's not a
replacement for PEP 671, nor is PEP 671 a replacement for it.
> Chris is welcome to push for a particular proposal. That is the purpose
> of the PEP process. He is also supposed to give dissenting arguments and
> alternatives fair airing in the PEP itself, even if only in a Rejected
> Ideas section.
>
At what point is an unrelated proposal a "rejected idea"? How
different does it have to be before it doesn't help to have it in that
section?
You're welcome to keep on arguing for the sake of arguing, but you're
not actually accomplishing anything by it. Especially since you're
rehashing the exact same complaints that you raised previously, and
which I responded, exactly the same way, at the time.
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/KPJ5TUWMEH4VKPEL2HJSTCJUD22Z5O7A/
Code of Conduct: http://python.org/psf/codeofconduct/
