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 select/ignore list of argument names for ARG rules #11359

Open
mal opened this issue May 10, 2024 · 4 comments
Open

Support select/ignore list of argument names for ARG rules #11359

mal opened this issue May 10, 2024 · 4 comments
Labels
configuration Related to settings and configuration

Comments

@mal
Copy link

mal commented May 10, 2024

Keywords: ARG, ARG001, unused arguments

In cases where I have wanted to turn the ARG rules on it's typically only been certain arguments I care about policing (especially where meta-programming is involved), so it would be nice to be able to select/ignore certain argument names on which for ARG to report.

This is achievable with minor local modifications to the original flake8 plug-in, but so far as I am aware there's no low-cast way to do the same in ruff.

@charliermarsh
Copy link
Member

You could use dummy-variable-rgx which I believe will ignore ARG rules for variables that match the pattern. But outside of that we'd need a dedicated setting. What are some examples of the names you wanted to ignore here, just to help w/ motivating use-cases?

@charliermarsh charliermarsh added the configuration Related to settings and configuration label May 10, 2024
@mal
Copy link
Author

mal commented May 11, 2024

In my case we have a dispatcher which inspects a function's signature to determine whether it should construct and send a context object. The construction of that object while not awfully slow, also isn't free. Sometimes we're able to refactor a handler function to remove the need for that context object, in which case the signature should be updated such that it never gets built or sent,

Using the ARG rules to check if this consistently named argument is ever unused is very appealing. At the same time, the code base is littered with various overridden methods (but being only py3.10, we don't yet have access to @typing.override), and monkey-patched functions which don't necessarily make use of all the args they must accept (and aren't suitable for that annotation afaiaa), so turning it on without being able to restrict it down the arg names we care about ends up filling the report with issues we can't easily resolve.

Unfortunately dummy-variable-rgx, being exclusionary and without support for lookaround (i.e. can't do ^(?!abc$)), means (at least so far as I am aware) that it's not possible to use it to only check certain names. Perhaps a more lightweight solution than a select/ignore system would be something like check-variable-rgx which would serve as the inverse to dummy?

I understand this is very edge-case-y and so I appreciate your taking the time to dig a little deeper. 🙂

@liiight
Copy link

liiight commented May 19, 2024

I got to this issue after encountering it as well. While I wasn't aware of @charliermarsh suggestion to use dummy-variable-rgx which i'll definitely try, I recommend taking a look at the source of the ARG rule as they use some configuration in that flake8 project: https://github.com/nhoad/flake8-unused-arguments?tab=readme-ov-file#flake8-unused-arguments

Perhaps some of that configuration could be ported for Ruff as well?

Thanks in advance by the way, Ruff is amazing!

@charliermarsh
Copy link
Member

Thanks! We do support ignore-variadic-names, and then we do most of those things by default (we ignore overloads, overrides, abstract methods, dunders, and stubs). @liiight are you looking to ignore a specific name / pattern here? Just wondering if adding a setting to allow certain unused names or patterns would solve your problem.

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

No branches or pull requests

3 participants