On Tue, 21 Jun 2022 at 09:20, Chris Angelico <ros...@gmail.com> wrote: > > 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.
OK, so maybe if you were a little less aggressive in your replies, we could see if anyone wants to respond. But frankly, I imagine it's hard to muster up any enthusiasm for writing up the semantics unless you're willing to show some sign that you might modify the PEP as a result. I'm not talking about rewriting your PEP to be a "deferred evaluation" PEP, but simply to modify it to make it more compatible with the future that the "deferred evaluation" people imagine. On the other hand, if the "deferred evaluation" supporters genuinely have nothing to offer other than "we don't want this PEP *at all* because what we have right now is sufficient in the short term, and longer term maybe something else (deferred evaluation being the possibility we can think of right now) will provide a different solution" then that's also OK. It's just a -1 vote, and should be recorded in the PEP as such - "A number of contributors on python-ideas were against this proposal because they didn't believe it offered enough benefit over the status quo, and they preferred to wait for a more general solution such as deferred evaluation (on the basis of the Zen "never is often better than right now")". That can still go in the "rejected ideas" section, under a heading of "Do Nothing". But unless we can reduce the level of conflict here, we're never going to know which alternative the deferred evaluation supporters want, and it won't be possible to accurately represent their views in the PEP. Which is bad for them (as they'll feel ignored) and for you (as your PEP won't fairly represent the views of the people who contributed to the discussion). Paul PS To be clear, my objections to the PEP aren't based on deferred evaluation. So I'm an impartial 3rd party on this matter. I *do* have problems with the PEP, so I have an interest in seeing the PEP fairly reflect the lack of consensus, and accurately represent the concerns people are raising, but I don't have a preference for any specific outcome in the matter of deferred evaluation. _______________________________________________ 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/PLQRTPEVRNU5VGVCRXDUV3ERSFX37RLF/ Code of Conduct: http://python.org/psf/codeofconduct/
