[Python-Dev] PEP 572: Assignment Expressions (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Apr 18 06🔞58 EDT 2018

On 18 April 2018 at 15:49, Jeroen Demeyer <J.Demeyer at 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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list