On Tue, Apr 24, 2018 at 10:56 AM, Chris Angelico <rosuav at gmail.com> wrote:
[..]
>> A lot of other questions arise though. PEP 572 proposes:
>>
>> a = 1 # assignment
>> a := 1 # also assignment
>> (a := 1) # also assignment
>> (a = 1) # error, why?
>
> Your third example is just the same as the second, with parentheses
> around it. In most of Python, parentheses (if legal) have no effect
> other than grouping; "a + b * c" is the same thing as "(a + b) * c",
> just done in the other order. The last one is a clear demonstration
> that "=" is a statement, not an expression. Are people confused by
> this sort of thing:
>
> if x > 1:
> print("x is more than 1")
> (if x > 1:)
> print("SyntaxError")
This is a very far-fetched example :)
My point was that when you see lots of '=' and ':=' used at the
statement level, one might try to write "if x = 1" instead of "if x :=
1" -- boom, we have an unexpected SyntaxError for some users.
In my opinion adding *any* assignment expression syntax to Python
*will* create this sort of issues. PEP 572 isn't free of them, my
proposal isn't free of them. My proposal doesn't add a new ':='
operator at the cost of slightly complicating rules around '='. PEP
572 avoids complicating '=', but adds an entirely new form of
assignment.
Yury
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4