On Tue, 21 Jun 2022 at 18:15, Paul Moore <p.f.mo...@gmail.com> wrote: > I'm not talking about a "full and detailed specification". That's > *still* more than is needed for a valid debate (at this point). But > what *is* needed is a more complete explanation of how deferred > evaluation would work, and some plausible (not set in stone, just > plausible) syntax. With that, it would be possible to write down two > versions of the same code and judge between them. We've not yet had a > sufficiently clear (IMO) definition of the semantics of deferred > evaluation yet (or if we have, it's been lost in the arguments), and > it would help a lot if someone could provide one. I'm thinking > specifically about the rules for variable capture, scoping, > interaction with assignment expressions in terms of introducing names, > etc., as well as how evaluation is "triggered" and what ability there > is to explicitly say "evaluate this now". >
That's what I mean by a full specification. Even without code, that would be enough to start talking about it. But those arguing "don't go for lazy evaluation, go for deferreds" don't seem to want to actually push that proposal forward. That's why I call it vapourware. 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/LVQUBGE74OXAT7IVVCOQJBKE5TNPINPN/ Code of Conduct: http://python.org/psf/codeofconduct/
