[pylint] Ignore stub files in import-private-name (PLC2701) - #27196
[pylint] Ignore stub files in import-private-name (PLC2701)#27196Avasam wants to merge 1 commit into
pylint] Ignore stub files in import-private-name (PLC2701)#27196Conversation
Stubs describe the runtime rather than being part of it, so importing a private name is often the only accurate option — re-exporting a private base class, or using the helper types in `_typeshed`. In `.py` files such imports are already exempt when used only in annotations, which does not help stubs where the import may be unreferenced or aliased. Closes astral-sh#15294 Closes astral-sh#15295
|
|
Hmm, I think there's still a decision needed here. The downside of hard-coding this exclusion is that now nobody can enforce this rule for their stub files, even if they wanted to. In some, or maybe most, cases the annotation may be out of the stub author's control, but I can at least imagine cases where it leads you to find a public re-export or something. The allowlist that Micha mentioned here or using per-file-ignores would be other ways of accomplishing this. I guess the rule is in preview, though, so we could just try it out. I also didn't think this would close #15294 since that seems to track support for a decorator, but you opened the issue, so I guess you can consider this closing it if you want :) |
ntBre
added
rule
|
Concerning #15294 and Another, holistic alternative, Finally, I completely forgot about https://docs.astral.sh/ruff/settings/#lint_per-file-ignores , which I totally already use in my own shared configs. If there's real value in keeping |
|
I feel less comfortable about this exclusion compared to other rules that make stub-file exclusions. I think the difference here is that a stub can use private types to declare its public interface. Those types aren't considered public and the stub maintainer can decide to change/delete these types in any release. E.g. a library can have a type alias to some internal type, where the internal type is different based on python version. The public API only uses the type alias. If your stub now reaches and uses the type alias target (the private type), then this is a private-name violation that won't be caught at the runtime side (and may also not be strictly necessary to truthfully type that module). |
|
Okay, let's close this for now and rely on |
3 participants
Summary
import-private-name (PLC2701)does not respect@type_check_only#15294import-private-name (PLC2701)for_typeshedimport #15295_typeshedimport in.pyfile should already be ignored by this rule if only used for annotations.Test Plan
Coding Agent disclaimer
Used Claude Opus 5 to help me generate complete test and reword in-code comments. PR description fully handwritten.