[ruff-0.10] [flake8-pyi] Stabilize preview-mode behaviours for custom-type-var-for-self(PYI019)

[AlexWaygood]

Summary

This PR stabilizes several preview-only behaviours for custom-typevar-for-self (PYI019). Namely:

• A new, more accurate technique is now employed for detecting custom TypeVars that are replaceable with Self. See [flake8-pyi] Significantly improve accuracy of PYI019 if preview mode is enabled #15888 for details.
• The range of the diagnostic is now the full function header rather than just the return annotation. (Previously, the rule only applied to methods with return annotations, but this is no longer true due to the changes in the first bullet point.)
• The fix is now available even when preview mode is not enabled.

Test Plan

• Existing snapshots that do not have preview mode enabled are updated
• Preview-specific snapshots are removed
• I'll check the ecosystem report on this PR to verify everything's as expected

[github-actions]

ruff-ecosystem results

Linter (stable)

ℹ️ ecosystem check detected linter changes. (+19 -0 violations, +0 -0 fixes in 5 projects; 50 projects unchanged)

apache/superset (+1 -0 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --no-fix --output-format concise --no-preview --select ALL

+ superset/sql/parse.py:167:21: PYI019 [*] Use `Self` instead of custom TypeVar `TBaseSQLStatement`

pandas-dev/pandas (+1 -0 violations, +0 -0 fixes)

+ pandas/_libs/tslibs/timedeltas.pyi:97:16: PYI019 Use `Self` instead of custom TypeVar `_S`

python/typeshed (+13 -0 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --no-fix --output-format concise --no-preview --select E,F,FA,I,PYI,RUF,UP,W

+ stdlib/_typeshed/__init__.pyi:331:16: PYI019 Use `Self` instead of custom TypeVar `Self`
+ stdlib/_typeshed/__init__.pyi:333:24: PYI019 Use `Self` instead of custom TypeVar `Self`
+ stdlib/typing.pyi:960:15: PYI019 [*] Use `Self` instead of custom TypeVar `_T`
+ stdlib/typing_extensions.pyi:237:15: PYI019 Use `Self` instead of custom TypeVar `_T`
+ stubs/PyYAML/yaml/representer.pyi:28:24: PYI019 [*] Use `Self` instead of custom TypeVar `_R`
+ stubs/PyYAML/yaml/representer.pyi:30:30: PYI019 [*] Use `Self` instead of custom TypeVar `_R`
+ stubs/protobuf/google/protobuf/internal/containers.pyi:36:18: PYI019 [*] Use `Self` instead of custom TypeVar `_M`
+ stubs/protobuf/google/protobuf/internal/containers.pyi:52:18: PYI019 [*] Use `Self` instead of custom TypeVar `_M`
+ stubs/protobuf/google/protobuf/internal/containers.pyi:76:18: PYI019 [*] Use `Self` instead of custom TypeVar `_M`
+ stubs/protobuf/google/protobuf/internal/containers.pyi:99:18: PYI019 [*] Use `Self` instead of custom TypeVar `_M`
+ stubs/protobuf/google/protobuf/message.pyi:30:21: PYI019 [*] Use `Self` instead of custom TypeVar `_M`
+ stubs/protobuf/google/protobuf/message.pyi:31:23: PYI019 [*] Use `Self` instead of custom TypeVar `_M`
+ stubs/protobuf/google/protobuf/message.pyi:34:19: PYI019 [*] Use `Self` instead of custom TypeVar `_M`

zulip/zulip (+2 -0 violations, +0 -0 fixes)

ruff check --no-cache --exit-zero --ignore RUF9 --no-fix --output-format concise --no-preview --select ALL

+ zerver/data_import/slack.py:109:18: PYI019 [*] Use `Self` instead of custom TypeVar `SlackBotEmailT`
+ zerver/lib/thumbnail.py:55:20: PYI019 [*] Use `Self` instead of custom TypeVar `T`

astropy/astropy (+2 -0 violations, +0 -0 fixes)

+ astropy/cosmology/_src/core.py:485:26: PYI019 Use `Self` instead of custom TypeVar `_FlatCosmoT`
+ astropy/cosmology/_src/flrw/base.py:1705:16: PYI019 Use `Self` instead of custom TypeVar `_FlatFLRWMixinT`

Changes by rule (1 rules affected)

code	total	+ violation	- violation	+ fix	- fix
PYI019	19	19	0	0	0

Linter (preview)

✅ ecosystem check detected no linter changes.

[AlexWaygood]

The ecosystem hits all LGTM

[MichaReiser]

Thank you

[MichaReiser]

Should we update both PEP names. It feels somewhat inconsistent to use a - here but not for PEP 673 (I don't think we have a standard for this but I suspect that no dash is more commonly used?)

[ntBre]

It looks like this PEP-695 is only used in a hyphenated expression ([PEP-695]-style), which probably explains the extra dash in this one.

[AlexWaygood]

yes, Brent has it exactly right. The unhyphenated form is usually preferred, so that's why "PEP 673" should remain unhyphenated in the docs above this. But PEP-695-style is a hyphenated expression, so it makes sense for the hyphen to remain there between "PEP" and "695"