Should have := expression assign like python instead of parenthese (e.g. (x = y) vs x = y) to indicate an expression assign in a Call vs a named parameter

[ehren]

parenthesized assignment is easy to miss in an elif clause especially:

if (cond:
    pass
elif (x = 5):  # did we mean assignment or did we mistype == but thought the elif syntax required parentheses like C?
    pass
)

should be

if (cond:
    pass
elif x := 5:
    pass
)

We should probably still keep the notion that assignment in a call e.g. foo(x=5) is a Call with a NamedParameter (even though there are a few issues with the current implementation) but we should require foo(x := 5) rather than foo((x = 5)) for an assignment expression in a call (regardless of the C++ unspecified order of evaluation gotcha with these).

Note: forget if we attempt to ban assignments in non-special (e.g. not "if" calls) already - there is some brokenness and hacks related to the handling of extra parentheses in if call args currently due to later parser changes.

[ehren]

OTOH, python still requires extra parentheses for := assignment expressions.

[ehren]

should clarify/correct the previous comment: python still requires extra parentheses for := assignment expressions because := is the lowest precedence operator. But there's additional rules about when extra parentheses are needed for := expressions listed at https://peps.python.org/pep-0572/ too. We'd want similar (and even more restrictive rules like banning a := b at block scope entirely - we don't want someone making a DSL via the macro system where e.g. x = y is a definition but x := y is a reassignment - that would be unpythonic!)

One problem with the extra rules listed at pep-0572 (especially mixing := and = in the same expression) is that tracking explicit redundant parentheses in a subexpression is where our current pyparsing RedundantParens_ hack falls down (it's ok for keeping track of the redundant parens when they appear at block scope or as the arguments of a call).

[ehren]

Another reason we need := is there are relatively few if statements in the codebase and testsuite that have an elif clause and a large number of elif clauses in the selfhost sources use assignment expressions (overparenthesized =) which gives you the ambiguous looking syntax in the first comment.

LLMs seem to have trouble with if statements with elif clauses in particular even though the extra parens vs python with all other control structures are handled ok (including ifs with no elif). Getting rid of examples like the first by adding := will cut down on the confusion.

Example: this gemini chat hilariously has a repeated miscounting of parentheses when you complain it hasn't balanced the parentheses in it's code properly https://gemini.google.com/share/7e74e64e49b8 (not even a strawberry issue because it counted correctly then claimed 4 = 5)