Implement Pylint #970

charliermarsh · 2022-11-30T04:52:53Z

This is the parent issue for tracking parity with Pylint. Below, we've enumerated all Pylint rules.

Rules that are checked off have been implemented in Ruff already (either as a Pylint rule, e.g., PLE0237, or by way of overlap with another linter like Pyflakes, as with missing-format-string-key).

Rules that are crossed out have been removed some consideration. (In most cases, crossed-out rules represent Pylint specific rules, e.g., rules related to Pylint configuration.)

At time of writing, many of the remaining rules require type inference and/or multi-file analysis, and aren't ready to be implemented in Ruff. (See: #970 (comment) for an enumeration.) If you're looking to start work on a specific rule, I'd suggest commenting in the issue, to get some input on whether Ruff is capable of supporting it at present.

For guidance on getting started, see the Contributing documentation.

Note: Don't implement rules that are part of Pylint extension until #1774 is completed. Don't implement rules that mainly target Python 2.

Error

Warning

Convention

Refactor

The text was updated successfully, but these errors were encountered:

charliermarsh · 2022-11-30T05:26:33Z

Need to figure out what the right "check code" approach is here. We could just start to put these under RUF. Or we could do PYE for "Pylint Error", and so on. Or we could use PYL for all of them. In either case, though, we have to allow four-digit codes, as opposed to our current three-digit codes.

JonathanPlasse · 2022-11-30T06:28:59Z

I vote for PYE as it would keep the same categories and the migration would be easier.

harupy · 2022-12-01T03:49:24Z

I'll work on unneeded-not this weekend.

relsunkaev · 2022-12-01T07:27:04Z

I would suggest PL as the pylint prefix (PLE -> PyLint Error). I think PYE might be a bit ambiguous with PYflakes, PYdocstyle, etc.

MartinBernstorff · 2022-12-01T09:33:12Z

Would absolutely love to see this happen. I know flake8 intentionally decided not to implement e.g. unexpected-keyword-arg because it required looking outside of the current file for imported functions.

I expect you've already considered this, and really hope this won't stop ruff from implementing it, but just wanted to raise it.

charliermarsh · 2022-12-01T15:22:58Z

@relsunkaev 👍 Went with PLE! The first code is checked in as PLE1142 (matching E1142 from Pylint).

charliermarsh · 2022-12-01T15:23:31Z

@MartinBernstorff - Definitely. The multi-file stuff will come, just not as quickly.

hmc-cs-mdrissi · 2022-12-08T02:41:23Z

Not sure if it should be separate issue, but looking at missing-function-docstring rule (C0116), pylint's version of it is different. It only requires that a function has docstring some in class hierarchy and does not require over-ridden methods to have a docstring. As an example,

class Foo:
  def validate(self):
    """Doc."""
    ...

class Bar(Foo):
  def validate(self):
    ...

gives no errors in pylint even though second validate is missing docstring being pylint allows inheriting one. This is very useful when implementing interface and the docstring would really be same for all things that subclass.

charliermarsh · 2023-01-05T18:53:47Z

I'd like to get pointless-statement, unnecessary-ellipsis, and unnecessary-pass in.

charliermarsh · 2023-01-05T19:20:12Z

Relevant source for defining a pointless-statement: https://github.com/PyCQA/pylint/blob/56121344f6c9c223d8e4477c0cdb58c46c840b4b/pylint/checkers/base/basic_checker.py#L447

thejcannon · 2023-01-12T16:08:49Z

A while ago I set out to find all the pylint codes make redundant by type checking.

Unfortunately that code got lost to the sands of time.

You might consider skipping those as type checking tools are very sophisticated, if you can do the effort of compiling that list

thejcannon · 2023-01-12T16:14:48Z

I've also thought very long and hard about the fact that pylint appears very sophisticated when it comes to types because it builds on astroid which works very hard to infer types based on code (pre-type-annotations)

Ideally ruff (or any modern linter) is type-aware to be as helpful as possible, but that requires either:

A Rust-implemented type checkers for Python. Short of a large company writing and maintaining this I doubt it'll keep up with the other big dogs
Having the type information be seeded to ruff. Aside from the overhead and protocol, this actually seems feasible.

dae · 2023-01-12T22:32:06Z

For what it's worth, the type awareness of pylint is the killer feature that keeps us using it in our project despite how painfully slow it is. Our first-party code is almost fully typed, and mypy is generally good at catching typing issues. We've found multiple instances where pylint caught an issue that mypy missed however - usually in third-party code with missing or incomplete type definitions, but occasionally also in our own code when mypy doesn't notice (eg due to the presence of __getattr__: python/mypy#6251).

thejcannon · 2023-01-12T22:41:02Z

Out of curiosity, have you tried pyright? It claims to have inference support for codebases that aren't fully typed.

dae · 2023-01-12T22:49:36Z

Mypy has a check_untyped_defs which sounds equivalent, and we use that. We currently rely on mypy's no_strict_optional which pyright has no equivalent to, so pyright is not currently usable on our codebase.

This PR adds [Pylint `R2004`](https://pylint.pycqa.org/en/latest/user_guide/messages/refactor/magic-value-comparison.html#magic-value-comparison-r2004) Feel free to suggest changes and additions, I have tried to maintain parity with the Pylint implementation [`magic_value.py`](https://github.com/PyCQA/pylint/blob/main/pylint/extensions/magic_value.py) See #970

ryanc-bs · 2025-03-12T16:34:27Z

hi, are there any plans on implementing the redefined-outer-name rule from pylint soon? Would find it useful as this can be a nasty source of bugs, for example in:

items = []
for i in range(10):
    items = get_new_items(i)  # shadowing outer variable name
    items.extend(items)

# items now only contains the results from the last iteration

InSyncWithFoo · 2025-03-12T16:37:39Z

@ryanc-bs There's #15903, but it only implements parts of the upstream rule (specifically, it won't emit any diagnostics for your example).

a1tus · 2025-03-24T14:02:43Z

@ryanc-bs There's #15903, but it only implements parts of the upstream rule (specifically, it won't emit any diagnostics for your example).

+1 for this rule, in our project it would be very useful for detecting accidental imports/global vars shadowing

ssbarnea · 2025-03-25T11:08:43Z

If I am not mistaken consider-using-re-compile appears to be missing and it should not be hard to implement. I should mention that pylint implementation is able to detect only re.search or re.match but not re.sub and the reality is that all 3 can benefit from it.

tusharsadhwani · 2025-03-25T12:57:51Z

@ssbarnea that sounds easy and useful, I'll take it up

vjurczenia · 2025-04-16T22:20:41Z

Hi, is anyone available to discuss implementing use-maxsplit-arg / C0207?

I decided to dive right into it here (if only to learn a bit more about Ruff), but got a little stuck when trying to imitate Pylint's behavior here which, to the best of my understanding, is what prevents the rule from triggering on just any function called split.

I'm thinking this may not be possible, but would appreciate confirmation from someone well-versed in the SemanticModel.

ntBre · 2025-04-17T17:22:23Z

Hi, is anyone available to discuss implementing use-maxsplit-arg / C0207?

I decided to dive right into it here (if only to learn a bit more about Ruff), but got a little stuck when trying to imitate Pylint's behavior here which, to the best of my understanding, is what prevents the rule from triggering on just any function called split.

I'm thinking this may not be possible, but would appreciate confirmation from someone well-versed in the SemanticModel.

has_builtin_binding comes to mind first for this, but I'm not sure it works on methods like str.split. An alternative could be to try resolving the type of the string with ResolvedPythonType or something like resolve_string_literal. I don't think you can override str.split, so if we know the method receiver is a str and the name is split, it should be safe to enforce the rule.

You can also look for other rules that operate on builtin method calls to see how they handle it, but I didn't find any obvious candidates in a quick search.

dylwil3 · 2025-04-17T18:04:59Z

I think the alternative suggestions is right and you just need to know whether you're looking at a string. Maybe is_string would do? It seems to be used here for bad-str-strip-call which is a similar sort of rule.

vjurczenia · 2025-04-17T22:20:14Z

Thanks @ntBre and @dylwil3, that did the trick! Your advice helped refine the test a bit too: I've added a test case for a class that inherits from str and overrides split. This shouldn't get flagged, and it doesn't.

As seen above, I've opened a PR with this change based on the instructions in the contribution guide. Please correct me if I'm wrong, but I assume now we simply wait until a maintainer decides to review. 🤞

serjflint · 2025-05-09T19:03:57Z

Hello! Now that ty is a thing (congratulations) is there any issue to track multi-file analysis in ruff? Some unimplemented rules here require it.

ntBre · 2025-05-09T19:20:56Z

Hello! Now that ty is a thing (congratulations) is there any issue to track multi-file analysis in ruff? Some unimplemented rules here require it.

Thank you! There is an issue for multi-file analysis (#7447), but I think we're still a while away from getting to use ty's capabilities here in ruff.

This PR adds a fix safety section in comment for rule PLE4703. parent: #15584 impl was introduced at #970 (couldn't find newer PRs sorry!)

kaddkaka · 2025-05-15T06:18:33Z

How should the documentation look when pylint rules are covered by rule from other ruleset? For example at https://docs.astral.sh/ruff/rules/#refactor-plr it looks like W0107 is not covered by ruff, but it's actually implemented as PIE790. Could the docs have a link from W0107 to PIE790?

We use ruff instead: E1002 super-on-old-class Python 2 only E1102 not-callable - R0201 no-self-use PLR6301 W0400 undocumented, perhaps W0404? W0404 reimported F811 W0511 fixme FIX001, FIX003 W0611 unused-import F401 W0612 unused-variable F841 W0614 unused-wildcard-import - Equivalent Pylint and ruff rules are tracked here: astral-sh/ruff#970

This PR adds a fix safety section in comment for rule PLE4703. parent: astral-sh#15584 impl was introduced at astral-sh#970 (couldn't find newer PRs sorry!)

NeilGirdhar · 2025-05-26T05:17:39Z

Could someone please mark:

use-yield-from / R1737
star-needs-assignment-target / E0114

Also, it seems like a lot of the remaining rules would be implemented by a type checker like Ty. Should a new issue be created for those rules that are supposed to be covered by Ty? Then these rules could be crossed off here?

MichaReiser · 2025-05-26T06:47:49Z

Also, it seems like a lot of the remaining rules would be implemented by a type checker like Ty. Should a new issue be created for those rules that are supposed to be covered by Ty? Then these rules could be crossed off here?

Our focus for ty's stable release is a type checker. We'll probably support more opinionated and lint-like rules in the future. That's why I don't think an "Implement pylint" issue would make sense at the moment (or even an "implement remaining pylint rules"). Opening issues for specific rules that are exclusively about correctness and fit the bill of a type checker can make sense.

NeilGirdhar · 2025-05-26T07:10:25Z

That's why I don't think an "Implement pylint" issue would make sense at the moment (or even an "implement remaining pylint rules"). Opening issues for specific rules that are exclusively about correctness and fit the bill of a type checker can make sense.

I understand, but I wasn't just talking about "opinionated and lint-like rules". I meant the rules that will be automatically implemented as a consequence of having a type checker. For example,

inconsistent-mro / E0240
invalid-metaclass / E1139
invalid-repr-returned / E0306
invalid-sequence-index / E1126
invalid-slice-index / E1127
invalid-slice-step / E1144
inherit-non-class / E0239
no-member / E1101
no-method-argument / E0211
no-name-in-module / E0611

These rules are not "opinionated". They are type errors that are caught by type checkers.

I suggest:

crossing these rules out from this issue as "implemented by a type checker", and
ensuring that the test cases for each of these rules is a test case in Ty's test suite.

I wonder how many rules would remain after all such rules were crossed out.

MichaReiser · 2025-05-26T07:13:55Z

That makes sense. I think we can do that once ty reaches a point where we can recommend it for productive use.

## Summary Implements `use-maxsplit-arg` (`PLC0207`) https://pylint.readthedocs.io/en/latest/user_guide/messages/convention/use-maxsplit-arg.html > Emitted when accessing only the first or last element of str.split(). The first and last element can be accessed by using str.split(sep, maxsplit=1)[0] or str.rsplit(sep, maxsplit=1)[-1] instead. This is part of #970 ## Test Plan `cargo test` Additionally compared Ruff output to Pylint: ``` pylint --disable=all --enable=use-maxsplit-arg crates/ruff_linter/resources/test/fixtures/pylint/missing_maxsplit_arg.py cargo run -p ruff -- check crates/ruff_linter/resources/test/fixtures/pylint/missing_maxsplit_arg.py --no-cache --select PLC0207 ``` --------- Co-authored-by: Brent Westbrook <[email protected]>

charliermarsh added the rule Implementing or modifying a lint rule label Nov 30, 2022

charliermarsh mentioned this issue Nov 30, 2022

How does ruff compare to pylint? #689

Closed

charliermarsh mentioned this issue Nov 30, 2022

Implement await-outside-async / E1142 #972

Merged

charliermarsh added plugin Implementing a known but unsupported plugin and removed rule Implementing or modifying a lint rule labels Dec 31, 2022

sbdchd mentioned this issue Jan 2, 2023

Implement flake8-pie #1543

Closed

7 tasks

max0x53 mentioned this issue Jan 12, 2023

Implement PLR2004 (MagicValueComparison) #1828

Merged

0xquark mentioned this issue Mar 14, 2025

Extend Pylint Rules in Ruff rucio/rucio#7499

Closed

davidsbatista mentioned this issue Mar 20, 2025

Update docstring and prevent name collisions deepset-ai/haystack#9078

Merged

BryanttV mentioned this issue Mar 25, 2025

feat: replace pycodestyle, isort and pylint with ruff openedx/openedx-filters#275

Open

13 tasks

carl-baillargeon mentioned this issue Apr 9, 2025

feat(anta): New AntaRunner class with limit concurrency aristanetworks/anta#680

Merged

4 tasks

jankatins mentioned this issue Apr 15, 2025

Update to modern packaging mystor/git-revise#141

Merged

vjurczenia mentioned this issue Apr 17, 2025

[pylint] Implement missing-maxsplit-arg (PLC0207) #17454

Merged

opk12 mentioned this issue Apr 24, 2025

new rule - not calling super() in custom exception's __init__() #8579

Open

yunchipang mentioned this issue May 3, 2025

[pylint] add fix safety section (PLE4703) #17824

Merged

ntBre pushed a commit that referenced this issue May 12, 2025

[pylint] add fix safety section (PLE4703) (#17824)

d545b5b

This PR adds a fix safety section in comment for rule PLE4703. parent: #15584 impl was introduced at #970 (couldn't find newer PRs sorry!)

DimitriPapadopoulos mentioned this issue May 15, 2025

MNT: Get rif of # pylint: pragma controls numpy/numpy#28972

Merged

This comment has been minimized.

Sign in to view

Implement Pylint #970

Implement Pylint #970

Comments

charliermarsh commented Nov 30, 2022 • edited by ntBre Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Error

Warning

Convention

Refactor

charliermarsh commented Nov 30, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JonathanPlasse commented Nov 30, 2022

Uh oh!

harupy commented Dec 1, 2022

Uh oh!

relsunkaev commented Dec 1, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MartinBernstorff commented Dec 1, 2022

Uh oh!

charliermarsh commented Dec 1, 2022

Uh oh!

charliermarsh commented Dec 1, 2022

Uh oh!

hmc-cs-mdrissi commented Dec 8, 2022

Uh oh!

charliermarsh commented Jan 5, 2023

Uh oh!

charliermarsh commented Jan 5, 2023

Uh oh!

thejcannon commented Jan 12, 2023

Uh oh!

thejcannon commented Jan 12, 2023

Uh oh!

dae commented Jan 12, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thejcannon commented Jan 12, 2023

Uh oh!

dae commented Jan 12, 2023

Uh oh!

ryanc-bs commented Mar 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

InSyncWithFoo commented Mar 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

a1tus commented Mar 24, 2025

Uh oh!

ssbarnea commented Mar 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tusharsadhwani commented Mar 25, 2025

Uh oh!

vjurczenia commented Apr 16, 2025

Uh oh!

ntBre commented Apr 17, 2025

Uh oh!

dylwil3 commented Apr 17, 2025

Uh oh!

vjurczenia commented Apr 17, 2025

Uh oh!

serjflint commented May 9, 2025

Uh oh!

ntBre commented May 9, 2025

Uh oh!

kaddkaka commented May 15, 2025

Uh oh!

NeilGirdhar commented May 26, 2025

Uh oh!

MichaReiser commented May 26, 2025

Uh oh!

NeilGirdhar commented May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MichaReiser commented May 26, 2025

Uh oh!

This comment has been minimized.

charliermarsh commented Nov 30, 2022 •

edited by ntBre

Loading

charliermarsh commented Nov 30, 2022 •

edited

Loading

relsunkaev commented Dec 1, 2022 •

edited

Loading

dae commented Jan 12, 2023 •

edited

Loading

ryanc-bs commented Mar 12, 2025 •

edited

Loading

InSyncWithFoo commented Mar 12, 2025 •

edited

Loading

ssbarnea commented Mar 25, 2025 •

edited

Loading

NeilGirdhar commented May 26, 2025 •

edited

Loading