More rules out of stub author's control

[Samuel-Therrien-Beslogic]

Ruff 0.8.0 ignores ambiguous-variable-name (E741) automatically in pyi files. This prompted me to look at other rules I disable specifically for .pyi files and found the following which I think should apply in all cases:

• PLR0904 https://docs.astral.sh/ruff/rules/too-many-public-methods/
• PLR0913 https://docs.astral.sh/ruff/rules/too-many-arguments/
• PLR0917 https://docs.astral.sh/ruff/rules/too-many-positional-arguments/
• PLW3201 https://docs.astral.sh/ruff/rules/bad-dunder-method-name/
• SLOT https://docs.astral.sh/ruff/rules/#flake8-slots-slot
• FBT https://docs.astral.sh/ruff/rules/#flake8-boolean-trap-fbt
• Possibly some of A https://docs.astral.sh/ruff/rules/#flake8-builtins-a
• Maybe PLC2701 https://docs.astral.sh/ruff/rules/import-private-name/

I haven't gone back and validated if these still trigger in stub files since I added them to our shared config, sorry if I tagged a rule that's already ignored.

[AlexWaygood]

Thanks! Your analysis all seems correct to me. I'd happily accept PRs disapplying these rules to stub files.

For E741 we were quite cautious, and made the change preview-only for several minor releases before stabilising the change. I don't think we need to be as cautious this time around. Our versioning policy states that it's fine to apply changes in patch releases if they reduce scope (and these would be reductions in scope); we only need to wait for a minor release if a change increases the scope of a rule.

[dylwil3]

The linked PR is for all but the last two bullets since those were suggested with less oomph 😄

[InSyncWithFoo]

@dylwil3 Is this issue resolved or is there something left to be done?

[dylwil3]

I leave that to @Samuel-Therrien-Beslogic to decide - as I said, I did not do anything regarding the last two bullet points. So it depends on whether there is interest in continuing to discuss those items.

[Samuel-Therrien-Beslogic]

Thanks @dylwil3 !

For PLC2701, I think that some users may still want a warning about using private names that are subject to change and suddenly break a stub, as per:

Further, as private imports are not considered part of the public API, they are prone to unexpected changes, especially outside of semantic versioning.

Instead, consider using the public API of the module.

But also

This rule ignores private name imports that are exclusively used in type annotations. Ideally, types would be public; however, this is not always possible when using third-party libraries.

(that last sentence is why I've been ignoring it, since more often then not there's no alternatives other than re-writing Aliases, TypeVars and Protocols)

So I'm not 100% convinced either way whether this should be disabled for everyone.

---

flake8-builtins (A)

The following I'm pretty sure should be disabled in stubs:

• A002 https://docs.astral.sh/ruff/rules/builtin-argument-shadowing/
• A003 https://docs.astral.sh/ruff/rules/builtin-attribute-shadowing/
• A005 https://docs.astral.sh/ruff/rules/builtin-module-shadowing/

As for the rest:

• A001 https://docs.astral.sh/ruff/rules/builtin-variable-shadowing/
  This could happen with aliases and other top-level variables. Non-runtime type aliases should be private in the first place. Devs also shouldn't try to import builtins from a module that happens to import said builtin. And finally this rule mostly tries to protect against using the shadowed variable. In a typing-only context, you should mostly be guarded by type tests anyway.
  I think this should be ignored in stubs.
• A004 https://docs.astral.sh/ruff/rules/builtin-import-shadowing/
  Very similar as A001 but can actually be worked around with import aliases and re-export aliases. (which would trigger A001 instead)
• A006 https://docs.astral.sh/ruff/rules/builtin-lambda-argument-shadowing/
  I don't think lambdas apply to type stubs anyway. Probably doesn't need to be ignored.

[harahu]

Just wanted to chime in and say that most if not all of the pep8-naming (N) rules should probably not be applied to stub files either.

[Avasam]

I did an experiment where I enabled nearly all rules in typeshed, and here's what I found typeshed would disable in PYI files (that isn't just an opinionated matter): https://github.com/Avasam/typeshed/pull/39/files#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711

• pep8-naming (N): As @harahu just mentioned, most pep8-naming rules don't apply for third-party stubs
  • But relevant rules could be made to apply to names decorated with @type_check_only, since that's a clear signal the stub author is very likely in control of that name.
  • N811, N812, N813, N814, N817 are probably fine in stubs, as long as the name isn't re-exported (in __all__, or var = var)
• A001, A002, A004 and PLC2701 as previously mentioned in More rules out of stub author's control #14535 (comment) (that's just my work account, same person here)
• PIE796 non-unique-enums: I already raised PIE796 false-positives on enum member cast in pyi files #15132 for different reasons
• FURB189 subclass-builtin: Stub author should follow runtime superclass when possible
• PLW1641 eq-without-hash: If runtime doesn't implement __hash__, stubs shouldn't show it as such
• flake8-bandit (S)
  • S105, S106, S107: Question/Request: Should S105, S106, S107 (Insecure hardcoded password) apply to stubs? #15206
  • S4: flake8-bandit's S4 rules don't apply to stubs #15207

As for opinionated rules: RUF022, RUF023, F403, F405 (caught by type-checkers), FURB180 (often breaks mypy/stubtest) are disabled for reasons specific to typeshed and can be kept out of this conversation.