[Python-Dev] PEP 572: Assignment Expressions

[Nick Coghlan]

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