[Python-Dev] PEP 572: Assignment Expressions

[Guido van Rossum]

Whereas I find it a deal-breaker for 'as'.

On Mon, Apr 23, 2018 at 3:15 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> On 04/23/2018 03:04 PM, Tim Peters wrote:
>
>> [Ethan Furman <ethan at stoneleaf.us>]
>>
>>> So I really like being able to make the assignment in the expression,
>>> but I
>>> have a really hard time parsing it with the name first.
>>>
>>> ...
>>>
>>> On the other hand, if it were using the "as" keyword:
>>>
>>> if (x - xbase as diff) and (gcd(diff, n) as g) > 1:
>>>      return g
>>>
>>> I would parse as:
>>>
>>>    if
>>>      x - x_base
>>>      as diff
>>>    and
>>>      gcd(diff, n)
>>>      as g
>>>    > 1:
>>>        return g
>>>
>>> For me at least, the last is much more readable.  Thinking about it some
>>> more, the problem (or maybe just my problem) is that I see an "if" or
>>> "while" and the I look for the thing that is True or False, and using the
>>> ":=" syntax the first thing I see is a placeholder for a result that
>>> doesn't
>>> exist yet, making me constantly scan backwards and forwards to put all
>>> the
>>> pieces in the correct place.
>>>
>>> With "as", it just flows forwards.
>>>
>>
>> I can read it fine either way, and don't much care.  A possible
>> advantage of an "as" operator is that its precedence could be set to
>> bind just a tad stronger than comparisons (which include "is" and "is
>> not" in Python), and then, e.g.,
>>
>>      if f() as result is not None:
>>          do something with result
>>
>> could work as intended.  So long as people can't get "assignment
>> _statements_" out of their heads,
>>
>>      if result := f() is not None:
>>
>> groups instead as
>>
>>      if result := (f() is not None):
>>
>> which would almost never be _intended_.  Maybe spelling it "as"
>> instead could break that.
>>
>> However, against "as" is that its current use in "with" statements
>> does something quite different:
>>
>>      with f() as name:
>>
>> does not bind the result of `f()` to `name`, but the result of
>> `f().__enter__()`.  Whether that "should be" fatal, I don't know, but
>> it's at least annoying ;-)
>>
>
> "as" does something slightly different in each of its current
> incantations, but the one thing that they all have in common is taking some
> thing on the left and giving it the name on the right:
>
> - imports -> thing on left gets name on right
> - exceptions -> exception that matches class on left gets name on right
> - with -> result of left.__enter__() gets name on right
>
> I see very little harm in adding
>
> - expression-binding -> eval(thing on left) gets name on right
>
> --
> ~Ethan~
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180423/fa013cc0/attachment-0001.html>