[Python-Dev] assignment expressions: an alternative proposal

[Anthony Flury]

On 24/04/18 14:50, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 24 April 2018 at 23:38, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>>> I propose to use the following syntax for assignment expressions:
>>>
>>>      ( NAME = expr )
>>>
>>> I know that it was proposed before and this idea was rejected, because
>>> accidentally using '=' in place of '==' is a pain point in
>>> C/C++/JavaScript.
>>>
>>> That said, I believe we can still use this syntax as long as we impose
>>> the following three restrictions on it:
>>>
>>> 1. Only NAME token is allowed as a single target.
>>>
>>> 2. Parenthesis are required.
>>>
>>> 3. Most importantly: it is *not* allowed to mask names in the current
>>> local scope.
>> While I agree this would be unambiguous to a computer, I think for
>> most humans it would be experienced as a confusing set of arcane and
>> arbitrary rules about what "=" means in Python.
> I respectfully disagree.  There are no "arcane and confusing rules"
> about "=", it's rather simple:
>
> "=" is always an assignment.
But it isn't - in your proposed syntax :

  * *<target> = <value>* is an assignment with no return value
  * *(<target> = <value>)* is an assignment with a returned value

   So now '=' is always an assignment, it is an assignment with extra 
semantics depending on surrounding syntax.

As discussed previously by others on this exact proposals, you now have 
the issue of  confusion when using keyword arguments : *my_func(a = b)* 
: clearly that is a call to `my_func' where argument a has the value of 
b, but if you want to do an assigment expression when calling the 
function you now have to do *my_func((a=b)) -* which frankly looks messy 
in my opinion; you get the same issue when you are wanting to do 
assignment expressions in tuples.

Using a different operator for assignments which return values avoids 
the messy potentially multiple level brackets, and means that the 
semantics of an operator depends only on that operator and not on syntax 
elements before and after it.

-- 
-- 
Anthony Flury
email : *Anthony.flury at btinternet.com*
Twitter : *@TonyFlury <https://twitter.com/TonyFlury/>*