On Tue, 21 Jun 2022 at 06:27, Chris Angelico <ros...@gmail.com> wrote: > > Okay, here's a compromise. > > Go and write a full and detailed specification of the Python-visible > semantics of deferred evaluation objects, including how they would be > used to implement late-bound argument defaults.
I'm going to ignore all the rhetoric here, as it's not helpful. I understand that you're frustrated, and that you feel like you're not getting your point across. Part of that (IMO) is *because* you're getting too frustrated, and so not explaining your point well. This is a case in point. Deferred evaluation doesn't need to be implemented to be a valid counter-proposal. Your repeated demands that someone produce an implementation are a distraction, allowing people to argue that you're wrong on that point, while ignoring the more important point. Which is that we don't really have a definition of how deferred evaluation would work. 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". > Go and actually do some real work on your pet feature, instead of > using the vapourware to try to shut down the one I've been working on. This is rhetoric again. Asking for more concrete examples of the proposed alternative is reasonable. Getting frustrated when they are not provided is understandable, but doesn't help. Calling the proposed alternative "vapourware" just doubles down on the uncompromising "implement it or I'll ignore you" stance. And replying with increasingly frustrated posts that end up at a point where people like me can't even work out how we'd go looking to see whether anyone *had* provided concrete examples of deferred evaluation just makes things worse. All of which could have been avoided by simply including an early argument posted here in the PEP, under rejected alternatives, with a link to the post and a statement that "this was proposed as an alternative, but there's not enough detail provided to confirm how it would replace the existing proposal". Then anyone who disagrees has a clear understanding of what you want, and how to provide it. > Once again, you're getting very very close to being killfiled. This whole discussion is close to that point for me. But believe it or not, I still have a vague hope that the proposal can be strengthened by people working together, rather than just ending up with a "this is what I think, take it or leave it" PEP. Paul _______________________________________________ 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/LZJF4P77YCTX5TM7JJ4VW64JD4DDTBN2/ Code of Conduct: http://python.org/psf/codeofconduct/
