[Python-Dev] assignment expressions: an alternative proposal
Anthony Flury
anthony.flury at btinternet.com
Tue Apr 24 10:54:03 EDT 2018
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/>*
More information about the Python-Dev
mailing list