On 24/04/18 14:50, Yury Selivanov wrote:
On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
On 24 April 2018 at 23:38, Yury Selivanov <yselivanov...@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.fl...@btinternet.com*
Twitter : *@TonyFlury <https://twitter.com/TonyFlury/>*
_______________________________________________
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
