[flake8-pyi] Implement PYI042 and PYI043

[arya-k]

PYI042 Type alias names should use CamelCase rather than snake_case
PYI043 Do not use names ending in "T" for private type aliases. (The "T" suffix implies that an object is a TypeVar.)

rel: #848

[github-actions]

PR Check Results

Ecosystem

ℹ️ ecosystem check detected changes. (+12, -0, 0 error(s))

typeshed (+12, -0)

+ stdlib/typing.pyi:735:1: PYI042 Type alias `_get_type_hints_obj_allowed_types` should be CamelCase
+ stubs/cffi/_cffi_backend.pyi:113:5: PYI042 Type alias `buffer` should be CamelCase
+ stubs/cffi/cffi/api.pyi:13:1: PYI042 Type alias `basestring` should be CamelCase
+ stubs/cffi/cffi/api.pyi:18:5: PYI042 Type alias `buffer` should be CamelCase
+ stubs/pika/pika/spec.pyi:9:1: PYI042 Type alias `_str` should be CamelCase
+ stubs/pywin32/pythoncom.pyi:10:1: PYI042 Type alias `error` should be CamelCase
+ stubs/pywin32/win32/odbc.pyi:9:1: PYI042 Type alias `_odbcError` should be CamelCase
+ stubs/pywin32/win32comext/adsi/adsi.pyi:7:1: PYI042 Type alias `error` should be CamelCase
+ stubs/pywin32/win32comext/propsys/propsys.pyi:6:1: PYI042 Type alias `error` should be CamelCase
+ stubs/pywin32/win32comext/shell/shell.pyi:7:1: PYI042 Type alias `error` should be CamelCase
+ stubs/redis/redis/typing.pyi:17:1: PYI043 Private type alias `_StringLikeT` should not be suffixed with `T` (the `T` suffix implies that an object is a `TypeVar`)
+ stubs/requests/requests/compat.pyi:22:1: PYI042 Type alias `builtin_str` should be CamelCase

Benchmark

Linux

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.01     17.1±0.09ms     2.4 MB/sec    1.00     16.9±0.06ms     2.4 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.00      4.1±0.01ms     4.1 MB/sec    1.00      4.1±0.01ms     4.1 MB/sec
linter/all-rules/numpy/globals.py          1.01    508.4±5.35µs     5.8 MB/sec    1.00    503.9±1.15µs     5.9 MB/sec
linter/all-rules/pydantic/types.py         1.00      7.0±0.03ms     3.6 MB/sec    1.00      7.0±0.04ms     3.6 MB/sec
linter/default-rules/large/dataset.py      1.00      8.3±0.02ms     4.9 MB/sec    1.01      8.4±0.02ms     4.9 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.00   1778.6±6.09µs     9.4 MB/sec    1.01   1797.0±4.76µs     9.3 MB/sec
linter/default-rules/numpy/globals.py      1.00    199.2±2.15µs    14.8 MB/sec    1.02    202.3±4.97µs    14.6 MB/sec
linter/default-rules/pydantic/types.py     1.00      3.7±0.01ms     6.9 MB/sec    1.01      3.7±0.06ms     6.8 MB/sec
parser/large/dataset.py                    1.00      6.6±0.02ms     6.2 MB/sec    1.00      6.6±0.01ms     6.2 MB/sec
parser/numpy/ctypeslib.py                  1.00   1275.4±1.81µs    13.1 MB/sec    1.00   1276.2±1.57µs    13.0 MB/sec
parser/numpy/globals.py                    1.00    129.8±0.50µs    22.7 MB/sec    1.00    130.1±0.33µs    22.7 MB/sec
parser/pydantic/types.py                   1.00      2.8±0.01ms     9.2 MB/sec    1.00      2.8±0.00ms     9.1 MB/sec

Windows

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.02     17.0±0.20ms     2.4 MB/sec    1.00     16.6±0.07ms     2.5 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.02      4.3±0.04ms     3.8 MB/sec    1.00      4.2±0.02ms     3.9 MB/sec
linter/all-rules/numpy/globals.py          1.01    437.8±5.24µs     6.7 MB/sec    1.00    434.6±5.04µs     6.8 MB/sec
linter/all-rules/pydantic/types.py         1.01      7.2±0.04ms     3.5 MB/sec    1.00      7.1±0.04ms     3.6 MB/sec
linter/default-rules/large/dataset.py      1.02      8.7±0.03ms     4.7 MB/sec    1.00      8.5±0.04ms     4.8 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.02  1844.1±27.13µs     9.0 MB/sec    1.00  1803.8±13.18µs     9.2 MB/sec
linter/default-rules/numpy/globals.py      1.01    197.1±5.68µs    15.0 MB/sec    1.00    195.4±4.30µs    15.1 MB/sec
linter/default-rules/pydantic/types.py     1.01      3.9±0.03ms     6.5 MB/sec    1.00      3.9±0.04ms     6.5 MB/sec
parser/large/dataset.py                    1.00      6.8±0.03ms     6.0 MB/sec    1.00      6.8±0.02ms     6.0 MB/sec
parser/numpy/ctypeslib.py                  1.00   1295.2±7.08µs    12.9 MB/sec    1.00   1292.1±6.03µs    12.9 MB/sec
parser/numpy/globals.py                    1.01    134.9±1.42µs    21.9 MB/sec    1.00    133.6±1.01µs    22.1 MB/sec
parser/pydantic/types.py                   1.01      2.9±0.03ms     8.8 MB/sec    1.00      2.9±0.02ms     8.9 MB/sec

[arya-k]

Hmm I'm not able to repro this test failure locally (macOS), when I run cargo test -p ruff_cli --test integration_test. I'm not quite sure what to make of this, and the CLI tests seem unrelated to my changes– do you have any tips @charliermarsh?

p.s. I'm pretty new to the ruff community: is it bad form to tag you like this?

[charliermarsh]

@arya-k - Not sure why I can't repro locally either, but I have a suspicion that we just hit a factor-of-two boundary and need to increase the RuleSet bit vector size. In short, we have a vector that needs to be long enough to match the number of total rules, and we may have just exceeded the previous limit. I tried pushing a fix, lets see what happens.

Also: totally fine to tag me or other maintainers.

[MichaReiser]

Thank you for your contribution.

I think we should try to implement these rules without having to rely on regular expressions. Regular expressions are great but can be overkill when matching on simple patterns and using plain string methods can then be better for performance

[arya-k]

Thank you for pushing this over the finish line- for my understanding, how did you format the python files? My installation of black produced a much larger diff so I ignored it.

[charliermarsh]

@arya-k - Oh interesting, I just ran Black from my own editor.

[charliermarsh]

I should correct that: we probably haven't run Black over all of our Python fixtures, so running black from root could produce a large diff. I just ran Black over the new fixtures in this PR.

[arya-k]

I should correct that: we probably haven't run Black over all of our Python fixtures, so running black from root could produce a large diff. I just ran Black over the new fixtures in this PR.

Ah got it. I ran it on all fixtures, then figured it wasn’t the way we were formatting python. Thanks for the clarification!