As well as all the matters Steven raises, I continue to dislike the proposal for the same reason I did on earlier rounds. I believe a general "deferred computation" mechanism is useful, but that one limited to the context of function parameters does more harm than good is scoped narrowly to that single use. I keyword version might bridge that gap by introducing "later" or "defer" or "delay" in a narrow context, but not foreclosing its later use more broadly.
On Wed, Jun 15, 2022 at 8:38 AM Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, Jun 14, 2022 at 11:59:44AM +0100, Rob Cliffe via Python-ideas > wrote: > > > I used to prefer `:=` but coming back to this topic after a long > > interval I am happy with `=>` and perhaps I even like it more, Chris.😁 > > The PEP status is "Draft". What are the chances of something happening > > any time soon, i.e. the PEP being considered by the Steering Committee? > > There's no Sponsor, so it isn't being considered by the SC. That much is > objectively true. > > Beyond that, the following is all my personal opinion, and should not be > taken as definitive or official in any way. Importantly, I have *not* > read back through the entire thread to refresh my memory. However, I > have re-read the PEP in detail. > > There's no consensus that this feature is worth the added complexity, or > even what the semantics are. The PEP punts on the semantics, saying that > the behaviour may vary across implementations. > > There's no consensus on the syntax, which may not matter, the Steering > Council can make the final decision if necessary. But with at least four > options in the PEP it would be good to narrow it down a bit. No soft > keywords have been considered. > > In my opinion, there are weaknesses in the PEP: > > - lack of any reference to previous discussions; > > - no attempt to gather feedback from other forums; > > - no review of languages that offer choice of early or late binding; > > - little attempt to justify why this is better than the status quo; the > PEP seems to take the position that it is self-evident that Python > needs this feature, rather than being a balanced document setting out > both pros and cons; > > - little or no attempt in the PEP to answer objections; > > - examples are all chosen to show the feature in the best possible > light, rather than to show both the good and bad; (e.g. no examples > show the parameter with annotations) > > - failure to acknowledge that at least one of the suggested syntaxes > is visually ambiguous with existing syntax. > > E.g. this would be legal with the PEP's second choice of spelling: > > def func(spam, eggs:=(x:=spam)): > > Even if the parser can distinguish the two uses of `:=` there, its > awfully cryptic. In and of itself, that's not necessarily a fatal flaw > (e.g. slicing) but the benefits have to outweigh the negatives, and the > PEP should be a balanced discussion of both. > > > > -- > Steve > _______________________________________________ > 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/V5K2JFT44A57ZXV2GS3OS6MQW2YKXMQN/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
_______________________________________________ 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/V2WTEHWFOL5LTW76QVGYMAGSNUAHOR6R/ Code of Conduct: http://python.org/psf/codeofconduct/
