Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

complex-if-statement-in-stub (PYI002) conflicts with if-with-same-arms (SIM114) #15153

Open
Avasam opened this issue Dec 26, 2024 · 2 comments
Open
Labels
rule Implementing or modifying a lint rule

Comments

@Avasam
Copy link
Contributor

Avasam commented Dec 26, 2024

In python/typeshed#13309 I found that the following rules can be in conflict:

Example:

import sys

if sys.version_info >= (3, 11):  # SIM114
    OP_IGNORE_UNEXPECTED_EOF: int
elif sys.version_info >= (3, 8) and sys.platform == "linux":
    OP_IGNORE_UNEXPECTED_EOF: int
import sys

if sys.version_info >= (3, 11) or (sys.version_info >= (3, 8) and sys.platform == "linux"):  # PYI002
    OP_IGNORE_UNEXPECTED_EOF: int

What would the recommendation be here? Could either rule be adapted so they work together ?

In this specific case, granted that typeshed's oldest supported Python version is 3.8, this could be adapted to:

import sys

if sys.version_info >= (3, 11) or sys.platform == "linux":
    OP_IGNORE_UNEXPECTED_EOF: int

But the underlying issue still exists.


Ruff 0.8.4

@MichaReiser
Copy link
Member

Thanks for opening this issue.

I see how the interaction here is unfortunate but I also worry that simplifying the boolean condition would require a SAT solver or similar, which seems a bit overkill, but I might be wrong on this.

While unfortunate, I do think that the current interaction between the two rules is reasonable:

  • It honors the user's intention to flag and fix identical-if-arms
  • It leaves it to the user to simplify the if condition OR to disable SIM114 if the condition can't be simplified.

@MichaReiser MichaReiser added the rule Implementing or modifying a lint rule label Dec 27, 2024
@Avasam
Copy link
Contributor Author

Avasam commented Dec 28, 2024

If the official recommendation is there's no better solution than to noqa and it's up to the dev to decide what they prefer. Then that answers my question. I wasn't sure if maybe I was missing something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule Implementing or modifying a lint rule
Projects
None yet
Development

No branches or pull requests

2 participants