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

Support disabling possibly-used-before-assignment in-line for specific variables #9738

Closed
avylove opened this issue Jun 18, 2024 · 2 comments

Comments

@avylove
Copy link
Contributor

avylove commented Jun 18, 2024

Current problem

With the introduction of possibly-used-before-assignment we've seen some errors come up in existing code. They are all cases where the code imports different libraries depending on if it is running on Windows or *nix. The guards in these cases are not direct. In one case, the Windows code is subclassed and in another the code is

I don't expect Pylint to figure out every case, but the current implementation only provides two options: disable the check universally or disable the check in-line. Of course there are some cases the code could be refactored, but that's not always possible or practical. In either case, one could easily mask legitimate issues.

Desired solution

Disable the check in-line for specific variables
This may look something like this:

if not IS_WINDOWS:
    import termios
...
if not IS_WINDOWS:
  attrs = termios.tcgetattr(fd)  # pylint: disable=possibly-used-before-assignment(termios)

In this case, for this line possibly-used-before-assignment is ignored for termios, but not for fd

I believe this also introduces a new general capability, i.e. the ability to fine tune in-line disables. This seems very useful as a general purpose capability, thought, without being familiar with the code, I can't be sure how difficult this would be to implement.

Additional context

No response

@avylove avylove added the Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling label Jun 18, 2024
@DanielNoord DanielNoord added Proposal 📨 Won't fix/not planned and removed Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling labels Jun 20, 2024
@DanielNoord
Copy link
Collaborator

Although this is an interesting idea I don't think it is feasible and would make our already overly complicated disable logic even more complicated.

If we were to redesign it from scratch I would definitely take it into consideration and if you're using ruff I'd recommend explaining this use case in astral-sh/ruff#3711 as it seems their issue of generating feedback about disables.

@DanielNoord DanielNoord closed this as not planned Won't fix, can't repro, duplicate, stale Jun 20, 2024
@Pierre-Sassoulas
Copy link
Member

We have a somewhat related issue to add reasoning in disables #5253

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants