On Tue, 21 Jun 2022 at 15:48, Brendan Barnwell <brenb...@brenbarn.net> wrote: > > On 2022-06-20 22:26, Chris Angelico 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. > > > > 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. > > > > Go and actually do something useful instead of just arguing that "it > > must be possible". > > I'm not the person you're replying to, but just a reminder here: there > is one alternative proposal that already has a fully functioning > implementation, namely the current behavior. Your arguments against the > deferred-evaluation proposal seem to constantly be reiterating that > there is no concrete deferred-evaluation proposal. You are right. But > your arguments also seem to be insinuating that if there is no such > proposal, then opposition to the PEP is somehow misguided, and that is > incorrect. There doesn't need to be any concrete alternative proposal > other than "leave everything as it is and wait until we think of > something better". > > It is perfectly valid to oppose your PEP even on the basis that maybe > a > deferred-evaluation proposal has a remote possibility of being better in > the future --- because it is perfectly valid to oppose your PEP even if > such a proposal has NO possibility of being better in the future. There > is no urgency or need for the behavior described in your PEP. I am fine > with the current behavior of Python in this regard. It is not necessary > to provide any alternative proposal, concrete or handwavy, to argue that > the PEP is a bad idea. I believe the PEP is a bad idea because the > current behavior of Python is actually better than what it would be if > the PEP were adopted. I believe it is better to wait until we think of > a better idea than to implement this PEP, and, if we never think of a > better idea, then never change the existing argument-default behavior of > Python.
I have laid out, multiple times, how a deferred evaluation feature is completely distinct from late-bound argument defaults. So have others. Steven continues to assert that, just because it MIGHT be possible to use them in the implementation, we should stop working on this and start working on that. He would, of course, be very welcome to work on deferred evaluation himself, but he chooses to hide behind his own ignorance of C to avoid doing any such work, and then still argues that we should stop working on this because, in his opinion solely, it would be more useful to have deferred evaluation. And then he calls me a liar for saying in the PEP the same thing that I've been saying here, yet he won't even write up a full specification for deferred evaluation. You are welcome to dislike the PEP on the basis that the existing language is better than it would be with this feature. I personally disagree, but that's what opinions are. But to object on the mere basis that something MIGHT, despite demonstrated evidence, be better? That is unfair and unhelpful. 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/7SIYYEJFFQ2MW2RKFGUI3HIEKGRJ6WGF/ Code of Conduct: http://python.org/psf/codeofconduct/
