A rule for walrus operator order?

[Fogapod]

if status := data["status"] == 1:
  ...

wrote this condition recently which is actually a bug because := has lowest priority of all operators. i have a few ruff rules as well as mypy enabled, none of them caught it (bool is subclass of int so mypy thought it's fine comparing it to ints later).

a quick search for walrus gives no results on ruff rules page. is there some rule to guard against this?

[charliermarsh]

I don't think we have anything like this yet. What would a good rule could look like here? Assert that walrus operators are always parenthesized if they're part of a larger expression?

[Fogapod]

Pretty much 99% of the the time I use walrus in if conditions like this where walrus is on the left and is/== on the right. So a rule forcing parens around walrus where other operators are present would work. Not sure how other people might be using it or what could be the edge cases

[charliermarsh]

We'd probably want to allow ok := (data["status"] == 0)?

[dhruvmanila]

Right, so if the parenthesis are present on the right side of the operator, then we don't want to flag it. If no parenthesis are present, we can provide a diagnostic to parenthesize the named expression, with a Suggested fix.

[rDarge]

Any update on this @charliermarsh @dhruvmanila ?
Fogapod's usage matches my/my teams usage and your proposed solution would be great

[dhruvmanila]

Unfortunately, there's no update here. The thing which is unclear to me is about the precedence the user intended to have. Is it that the user wanted to have comparison done first or is it that the assignment should be done first? It's not possible to know that without the parentheses. We could assume that if the user have enabled this rule, it's intended to always parenthesize the named expression unless the value of the expression is already parenthesized. What do you think? @charliermarsh

[bluetech]

Would like to note that there are other "confusing precedence" cases which might be considered along with this one. One I see occasionally is

a == b if c else d

which is evaluated as

(a == b) if c else d

while the following is sometimes intended

a == (b if c else d)

I think it would be good to require clarifying parentheses here.

Does the Ruff AST allow checking for parens, or will it require a tokens-level rule? (A tokens rule might get complicated...)