Whereas I find it a deal-breaker for 'as'. On Mon, Apr 23, 2018 at 3:15 PM, Ethan Furman <et...@stoneleaf.us> wrote:
> On 04/23/2018 03:04 PM, Tim Peters wrote: > >> [Ethan Furman <et...@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@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)
_______________________________________________ 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