On 18 April 2018 at 15:49, Jeroen Demeyer <j.deme...@ugent.be> wrote: > On 2018-04-18 02:13, Chris Angelico wrote: >> >> I'm much happier promoting a full-featured assignment expression than >> something that can only be used in a limited set of situations. Is >> there reason to believe that extensions to the := operator might take >> it in a different direction? If not, there's very little to lose by >> permitting any assignment target, and then letting style guides frown >> on it if they like. > > > This is a very good argument: why artificially restrict the operator? > > This reminds me of the artificial restriction of decorator syntax (why is > @foo()() not legal?). There was never a rationale given for that and now we > are stuck with it.
That's not the case - Guido's given in-principle approval for the decorator restriction to be lifted (I believe primarily due to the validity of the "@ns[lookup]" case), but it's never irritated anyone enough for them to do the work to propose the necessary grammar and reference implementation changes (vs using a pass-through function like "@decorator(ns[lookup])" to bypass the restriction). So what these kinds of initial restrictions do is require that any extra complexity be justified *in its own right*, rather than coming along for the ride as part of proposals with motivating use cases that only require much simpler capabilities (names and calls in the case of decorators, names in the case of assignment expressions). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com