Implement Pylint

Question

Implement Pylint

charliermarsh opened this issue 2 years ago · 278 comments

Answer 1 · 2022-11-30T05:26:33.000Z

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.

Answer 2 · 2022-11-30T06:28:59.000Z

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

Answer 3 · 2022-12-01T03:49:24.000Z

I'll work on unneeded-not this weekend.

Answer 4 · 2022-12-01T07:27:04.000Z

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

Answer 5 · 2022-12-01T09:33:12.000Z

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.

Answer 6 · 2022-12-01T15:22:58.000Z

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

Answer 7 · 2022-12-01T15:23:31.000Z

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

Answer 8 · 2022-12-08T02:41:23.000Z

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.

Answer 9 · 2023-01-05T18:53:47.000Z

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

Answer 10 · 2023-01-05T19:20:12.000Z

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

Answer 11 · 2023-01-12T16:08:49.000Z

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

Answer 12 · 2023-01-12T16:14:48.000Z

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.

Answer 13 · 2023-01-12T22:32:06.000Z

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).

Answer 14 · 2023-01-12T22:41:02.000Z

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

Answer 15 · 2023-01-12T22:49:36.000Z

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.

Answer 16 · 2023-01-21T15:54:05.000Z

Started to look at import-error / E0401,

From what i can tell - ruff doesn't currently use any "context" about the python environment, right?
In order to add this rule - we need to use something like pkgutil - which can be slow, or implement import resolution in ruff.

@charliermarsh Is the project open to any of these options currently?

Answer 17 · 2023-01-21T18:17:35.000Z

We have some support for import resolution, but not enough to power import-error right now.

What we do support is (1) a src list, which is used for first-party resolution, similar to isort and reorder-python-imports (so it detects module-level first-party imports, but doesn't do "full" resolution), (2) a namespace-packages list, for namespace packages, and (3) we do crawl the filesystem to find all __init__.py files to power some checks.

Does import-error need to be able to lookup third-party packages?

Answer 18 · 2023-01-21T19:07:27.000Z

Does import-error need to be able to lookup third-party packages?

FWIW this is one of the biggest reasons we use pylint at all, despite obviously being much slower to do than just first party code.

Answer 19 · 2023-01-21T22:15:35.000Z

Any plans on when and how to implement more import resolution features?

WDYT about creating an issue to gather rules that will need these capabilities?

Answer 20 · 2023-01-26T04:27:22.000Z

I just went through and mapped all the checked-off rules to the relevant codes within Ruff. I'm guessing we implement more than the 86 that are checked off (at time of writing), but it's my best guess based on a single pass through the list.

Answer 21 · 2023-01-30T15:05:45.000Z

It’d be really nice if ruff can understand the inline pylint ignores to make migration very easy.

Answer 22 · 2023-01-30T15:06:55.000Z

It’d be really nice if ruff can understand the inline pylint ignores to make migration very easy.

this is covered in #1203

Answer 23 · 2023-02-04T18:39:39.000Z

We can probbably mark bad-configuration-section as complete, it has to do with a pylint refactor

Answer 24 · 2023-02-04T18:45:37.000Z

useless-option-value too, it's a warning for an issue in the pylint configuration.

Answer 25 · 2023-02-04T18:56:02.000Z

bad-plugin-value is also for pylint plugins that cannot be loaded, which we do not need.

Answer 26 · 2023-02-04T19:29:17.000Z

Thank you! Going to strike them out.

Answer 27 · 2023-02-05T15:05:29.000Z

What's the policy with duplicate logic being checked by multiple linters? E.g. too-many-format-args seems functionally equivalent to F524 which is already implemented:

https://github.com/charliermarsh/ruff/blob/41900316186ae65b588ec0fda64c21bfee4b9956/src/rules/pyflakes/rules/strings.rs#L191

Answer 28 · 2023-02-05T15:10:23.000Z

We tend towards including the Flake8 variant over the Pylint variant. We're working on enabling rule aliasing, so that we'll be able to map multiple codes to the same underlying rule (details TBD).

Answer 29 · 2023-02-07T01:28:02.000Z

@charliermarsh do we have anyway of knowing the minor version of python we are on? broken-collections-callable should only be run on python 3.9.0 and 3.9.1, and I don't know of a way to detect only those two sub-versions.

Answer 30 · 2023-02-07T02:36:26.000Z

@colin99d - Hmm -- not really. I think we should just skip that rule.

Answer 31 · 2023-02-07T08:10:40.000Z

Just my two cents, but from working on pylint for some time we have seen the definite need to specify the expected python version, preferably with the config option py-version which is slowly becoming a standard within the python ecosystem. It might be nice to support such an option as well.

Answer 32 · 2023-02-08T00:34:17.000Z

@charliermarsh, do we have any way of knowing that the name token data is a dict, particularly if the item is defined in a different file.

data = {'Paris': 2_165_423, 'New York City': 8_804_190, 'Tokyo': 13_988_129}
for city, population in data:  # [dict-iter-missing-items]
    print(f"{city} has population {population}.")

Answer 33 · 2023-02-08T03:08:38.000Z

@colin99d - No, unlike Pylint we don't have that capability right now.

Answer 34 · 2023-02-16T06:52:20.000Z

@charliermarsh Would love to understand the T-shirt size effort for E0611 (before I take the time to dive into the code base for contribution) and how likely it is to be part of ruff.

I guess the simplest example would be:

from requests import aaa

Would pass on ruff or flake8, on pylint, i'd get:

E0611: No name 'aaa' in module 'requests' (no-name-in-module)

Answer 35 · 2023-02-16T17:53:31.000Z

@AvnerCohen - I would call that a "Large". Ruff operates under a single-file model right now, so each file is analyzed in isolated (though we do some traversals upfront to infer the package hierarchy etc.). To power something like that, we need to move to a model in which we do some analysis of the available members in each module as a first pass, then enforce lint rules as a second pass. It's within scope, but it's a significant feature more-so than a single rule, if that makes sense :)

Answer 36 · 2023-02-16T17:59:45.000Z

Related to #2914 -- I've posted some more commentary in there.

Answer 37 · 2023-02-18T12:46:58.000Z

The pylint rules implemented by PyCharm: #2972

Answer 38 · 2023-02-19T19:08:16.000Z

The pylint rules implemented by PyCharm: #2972

Opened a new issue for PyCharm inspections covered and not covered by PyLint here, since #2972 may soon be closed: #3040

Answer 39 · 2023-02-26T04:07:17.000Z

I was looking at maybe implementing E0203 along with some others that are of the same ilk, but I noticed that, at least in my noddy testing and reading around, we don't really seem to keep track of these neither per scope. Would the sensible thing be to push a new Binding onto the bindings member of the Checker in checkers/ast.rs? If so, what sort of Binding? Binding::Binding?

Answer 40 · 2023-02-26T16:56:48.000Z

I'll do invalid-character-*

Answer 41 · 2023-02-27T16:09:47.000Z

@charliermarsh What is the suggested approach to configure a project so as to have Ruff subsume Pylint, where both implement the same checks? Right now, we have lot of duplicate warnings.

Answer 42 · 2023-02-28T07:57:58.000Z

W0123 is an overlap of PHG001, so I guess that could be ticked off?
Same goes for W0122 with S102. 👍🏻

Answer 43 · 2023-03-07T02:04:15.000Z

For convenience, this page in the Pylint documentation lists all of the Pylint rules, with links to descriptions and examples of each: https://pylint.pycqa.org/en/latest/user_guide/messages/messages_overview.html.

Answer 44 · 2023-03-19T16:17:21.000Z

@charliermarsh , I've began work on implementing duplicate-argument-name / E0108, however, the parser throws an error when attempting to parse the test Python file. Does this mean it can be closed off as already implemented or is there something I can alter elsewhere? :)

cargo run -p ruff_cli -- check crates/ruff/resources/test/fixtures/pylint/duplicate_argument_name.py --no-cache --select PLE0108 
   Compiling ruff v0.0.257 (/home/jacoblatonis/Projects/ruff/crates/ruff)
   Compiling ruff_cli v0.0.257 (/home/jacoblatonis/Projects/ruff/crates/ruff_cli)
warning: `ruff` (lib) generated 3 warnings
    Finished dev [unoptimized + debuginfo] target(s) in 21.66s
     Running `target/debug/ruff check crates/ruff/resources/test/fixtures/pylint/duplicate_argument_name.py --no-cache --select PLE0108`
error: Failed to parse crates/ruff/resources/test/fixtures/pylint/duplicate_argument_name.py: duplicate argument 'first_name' in function definition at line 1 column 39

Answer 45 · 2023-03-19T19:13:38.000Z

@latonis - Ah yeah, we can't support that one right now, since it's not valid Python. It's sort of debatable whether Ruff should support that.

Answer 46 · 2023-03-19T19:15:56.000Z

Type checkers ought to flag that as invalid syntax. Or running the code under tests.

Maybe at the most ruff flags it can't operate because there's a syntax error at and well there's your failure

Answer 47 · 2023-03-19T19:18:04.000Z

👍 Yeah Ruff would flag that there's a syntax error in that file, and would probably tell you where / what it is but I haven't tested that specific case.

Answer 48 · 2023-04-17T13:51:46.000Z

The table above suggests ruff implements cell-var-from-loop, but it doesn't show up in the documentation or on the command-line with ruff check. Is it implemented under a different name, or was that a mistake and it's not actually implemented?

Answer 49 · 2023-04-17T13:56:27.000Z

Ah, cell-var-from-loop is equivalent to B023. For ease of switching for pylint users, then, might be handy to alias B023 as PLW0640, if aliasing is supported.

Answer 50 · 2023-04-18T12:07:23.000Z

Hey folks, Thanks a lot for this awesome project!

I have scrubbed over the list of pylint checks and it looks like (at least) no-name-in-module / E0611 would require leveraging the new ImportMap feature.

Also, producing a proper implementation of no-member / E1101 seems significantly more involved.

Are there any plans to work on these? I wish I could help but I am a bit clueless about rust...

Answer 51 · 2023-04-18T12:46:30.000Z

Hey folks, Thanks a lot for this awesome project!

I have scrubbed over the list of pylint checks and it looks like (at least) no-name-in-module / E0611 would require leveraging the new ImportMap feature.

Also, producing a proper implementation of no-member / E1101 seems significantly more involved.

Are there any plans to work on these? I wish I could help but I am a bit clueless about rust...

It's something I would like to do after finishing the work on detecting cyclic imports. The ImportMap only shows what a module imports, not exports, but I suppose a similar type of approach would be needed whereby after traversing a module, I guess we could have anExportMap if you will of the names available.

Answer 52 · 2023-04-18T15:06:43.000Z

Chris Chan, Apr 18, 2023 at 14:46:

It's something I would like to do after finishing the work on detecting cyclic imports. The `ImportMap` only shows what a module imports, not exports, but I suppose a similar type of approach would be needed whereby after traversing a module, I guess we could have an `ExportMap` if you will of the names available.

Awesome. I guess it also requires to determine where these imports should be resolved, check if there is a virtualenv, that sort of thing. How far do you intend to go in code inspection to be able to do type checking? Do you plan on introspecting compiled extensions? How about type stubs (`.pyi`)? Pylint relies on astroid to do such things. And I remember having to patch it to support compiled extensions: pylint-dev/astroid@2da60a0. Which (by the way) was easily broken a bit later on: pylint-dev/pylint#7399. I will gladly help if I can.

Answer 53 · 2023-04-18T15:54:06.000Z

@rjarry I have to admit, I wasn't planning on doing it, I don't know what the wider plans are for ruff, I do know that ruff uses RustPython's parser, and to be honest, I don't know how t RustPython works, but if has an analogue to .pyc files, maybe we could. But it would be something I would need to learn/understand in order to do so.

Answer 54 · 2023-04-20T15:51:22.000Z

Can RustPython make a very small interpreter enough to import names?
The import rules of python are very complicated and depending on comparably bigger library _imp, _frozen_importlib etc

Answer 55 · 2023-04-21T01:53:04.000Z

Performance hit from using real interpreter for just imports can be pretty high especially as some python files run logic at module level (metaclasses/init_subclass/any global code). There are major libraries like tensorflow where just importing them takes several seconds.

Answer 56 · 2023-04-21T06:29:13.000Z

Can we and/or PyLint instead use CPython audit events to record imports? https://docs.python.org/3/library/audit_events.html

Answer 57 · 2023-04-21T12:42:41.000Z

Linters don't run code. Any runtime construct is likely not useful here.

Answer 58 · 2023-04-21T13:56:18.000Z

Why do you think that is necessarily true? Have you read #970 (comment)?

Answer 59 · 2023-04-21T17:37:05.000Z

Some linters run code. Various others do not for multiple reasons. In ruff’s case one major core feature is performance. Running real imports can be very slow and for some files could immediately make ruff orders of magnitude slower. Python files are allowed to run whatever code they want at import time and some libraries do non trivial initialization when imported. It may also be mild security concern although most use cases if you lint a file you typically trust content in that file.

pyright is one static analysis tool that avoids almost all imports/runtime execution for those reasons. I think mypy is the same. Some tools do choose to accept trade offs of runtime imports and use them. Given ruff’s focus on performance I don’t think it makes sense for ruff to do them.

Answer 60 · 2023-04-30T22:18:26.000Z

I'm peaking at subprocess-run-check / W1510. It's not a particularly important check, but the fix is pretty simple, to just add a new parameter to the function call check=True. But it get's a little complicated to me if the function is formatted across more than one line.
If anyone has any suggestions of any other similar fixes where a parameter is added to a method that I could use as an example, I'd like to take a stab at this simple case.

Answer 61 · 2023-04-30T22:56:30.000Z

I'm peaking at subprocess-run-check / W1510. It's not a particularly important check, but the fix is pretty simple, to just add a new parameter to the function call check=True. But it get's a little complicated to me if the function is formatted across more than one line. If anyone has any suggestions of any other similar fixes where a parameter is added to a method that I could use as an example, I'd like to take a stab at this simple case.

I've not tried it, but it should be in the 'args' member of the StmtKind::FunctionDef struct
Another issue to consider is that a user might have imported subprocess under an alias, but you should test how pylint deals with it, or even look at the source for pylint to find out how it's done.

Answer 62 · 2023-04-30T23:28:13.000Z

Pylint uses astroid, so I wouldn't be surprised if it understands aliases pretty well.

That being said, don't let perfect be the enemy of good enough. It isn't something that is usually aliased, and reporting on the simple case is worth it to do now, and improve later.

I don't think @charliermarsh or any of the Astral folks have mentioned how type information (or any information not easily gleamable from an AST) will make it into ruff, so doing the easy thing is likely the first pass at any of these

Answer 63 · 2023-04-30T23:38:56.000Z

Pylint uses astroid, so I wouldn't be surprised if it understands aliases pretty well.

That being said, don't let perfect be the enemy of good enough. It isn't something that is usually aliased, and reporting on the simple case is worth it to do now, and improve later.

I don't think @charliermarsh or any of the Astral folks have mentioned how type information (or any information not easily gleamable from an AST) will make it into ruff, so doing the easy thing is likely the first pass at any of these

This is true, but we could track those aliases considering the Import/ImportFrom StmtKind structs have that information, we already track imports per module as it is.

Answer 64 · 2023-04-30T23:56:01.000Z

https://github.com/search?q=repo%3Apylint-dev%2Fpylint%20subprocess-run-check&type=code
So...pylint just does the basic check.

Answer 65 · 2023-04-30T23:56:40.000Z

@chanman3388 - Thankfully we do handle alias tracking and it's largely abstracted away in end-user code. If you grep around for calls to resolve_call_path, this returns the absolute path for an expression, so it handles aliased imports, import-froms, etc. This is what we tend to use across Ruff to check (e.g.) "Is this expression a call to subprocess.check_call?" (Note that this doesn't handle code like import subprocess; foo = subprocess; foo.check_call, we treat those as independent bindings right now; but it does handle code like import subprocess as foo; foo.check_call.)

Answer 66 · 2023-05-01T00:01:18.000Z

@dciborow - Sounds like you're mostly wondering how to construct the proper fix, even in the event that the function arguments are split over multiple lines, etc. -- is that right? We have crates/ruff/src/autofix/actions.rs#remove_argument which is similar. You could write an add_or_replace_argument helper with a similar structure.

In general, I think you want to find the last argument in the call, and then insert a comma (if there's no trailing comma), and then insert the argument -- unless the argument is already present in the call, in which case you just want to replace its value. This will require some mix of looking at the AST (to see if the argument is present) and looking the token stream (to see if there's a trailing comma). The method I mentioned above does some of that kind of stuff, as an example.

Answer 67 · 2023-05-01T15:23:54.000Z

@charliermarsh , thanks!

I had been working on adding auto-fixes to our vscode-pylint plugin, (this one got more complicated then my easy regex fixer can handle) but was recommending to check out Ruff, and find that it runs a lot faster inside of VS Code. I also like that I can use rust to auto-fix things outside of VSCode. So, while I have never written Rust before, excited to see what I can figure out.

Answer 68 · 2023-05-02T04:07:15.000Z

A lot of good, useful Pylint lints require at least some type inference to be useful (even if it's as rudimentary as backtracking through assignments), and that's probably the thing that I'm interested in the most from Ruff.

If such an inference system starts building up, it might give the project momentum to finish through the pylint port. It'd make auto fixes much easier as well.

Answer 69 · 2023-05-05T00:08:43.000Z

E0102 seems to be already covered by pyflakes F811?

Answer 70 · 2023-05-10T14:55:03.000Z

no-value-for-parameter / E1120 is what I expected to be implemented, any timelines on this or how I can enable it manually(within ruff)?

Nevermind, It's not covered by Pyflakes rules so probably impossible to implement

Answer 71 · 2023-05-10T15:30:12.000Z

it's not implemented right now. I'd assume it's fairly hard to implement, at least to the degree that pylint can detect.

Answer 72 · 2023-05-12T14:21:29.000Z

Now that E1206, E1205 are implemented, seems like E1306, and E1305 would be good first issues if someone wants to take it up. Can we also tag this issue as good first issue @charliermarsh ? Lots of easy to implement rules here.

Answer 73 · 2023-05-12T14:50:06.000Z

i'll take a look at E1306 and E1305

Answer 74 · 2023-05-12T14:51:48.000Z

Those specific rules might actually be covered by existing Pyflakes rules. I think E1306 is the same as F522, and E1305 is the same as F524?

Answer 75 · 2023-05-12T14:57:15.000Z

@charliermarsh yup - that looks right.
should we add anything to the code to make it clear that they also cover the pylint rules?

Answer 76 · 2023-05-12T14:57:48.000Z

@alonme - For now, I'll just mark them as completed here and reference those tasks. In the future, we will mark them as aliases in the code, but there's no support for that right now.

Answer 77 · 2023-05-12T15:42:42.000Z

cool,
taking a look at E0112

EDIT:
oh well seems like that is also covered by F622

Answer 78 · 2023-05-12T15:51:15.000Z

and i am not sure if E6004 is worth implementing as it is only relevant in python 3.7.0 and 3.7.1, and python 3.7 will be EOL in a month or so

Answer 79 · 2023-05-12T16:18:11.000Z

Calling out a few that look like good-first-rules: E1003, E0241, W0130, W0131.

Answer 80 · 2023-05-17T00:26:39.000Z

Unfortunately E1003 is not as easy as it looked due to classes inheriting others.

So PLE1003 will be on-hold until we get a way to track down the inherited parents.

Answer 81 · 2023-05-17T07:17:30.000Z

@nm-remarkable Hey!

Can you maybe create a separate issue/discussion about all the pylint lints that seem hard to implement? I can collaborate and help create a knowledge base for other collaborators.

Or, we can talk over text or email if that suits better.

Answer 82 · 2023-05-18T04:55:33.000Z

I'll take a look at W0130 and W0131.

Answer 83 · 2023-05-19T15:28:32.000Z

W0706 is already implemented as TRY302.

Answer 84 · 2023-05-19T16:24:02.000Z

Hey folks, I'm interested in taking on so of this work. I have a rough draft for PLE1128 already, how would I go about pushing that up for review?

Answer 85 · 2023-05-19T16:26:37.000Z

@wiwa5606 creating a fork of this repository on your own account and then making a pull request should be good

Answer 86 · 2023-05-19T16:27:38.000Z

Hey folks, I'm interested in taking on so of this work. I have a rough draft for PLE1128 already, how would I go about pushing that up for review?

If you have it in a branch on your fork, then GitHub should give you the option to create a pull request. Normally you would do this from your fork. You can take a look at the merged issues higher up for what these look like. I hope that answers your question!

Answer 87 · 2023-05-19T16:35:29.000Z

Thanks, that helps! Raised #4532

Answer 88 · 2023-05-19T17:48:35.000Z

W0707 is an alias for TRY200

Answer 89 · 2023-05-19T17:52:11.000Z

W1201is also implemented as combination of several rules logging-format G

Answer 90 · 2023-05-19T19:54:42.000Z

I am looking into E1111

Answer 91 · 2023-05-22T15:12:52.000Z

I would really need W1203, in the next days maybe I can start working at it

Answer 92 · 2023-05-22T15:38:11.000Z

@DavideCanton Isn't W1203 already implemented as one of the logging-format rules G?

Answer 93 · 2023-05-22T15:43:38.000Z

@Skylion007 oh, I didn't know there was a flake8 plugin for that too :/ thanks for your help!

Answer 94 · 2023-05-27T13:13:06.000Z

Some notes about various listed codes:

return-arg-in-generator/E0106 probably should not be implemented as it only applies to dead versions of Python (3.3 and earlier).
unknown-option-value / W0012 probably shouldn't be implemented either, as it's specific to pylint error codes.
using-f-string-in-unsupported-version / W2601 probably shouldn't be implemented as it only applies to dead versions of Python (3.5 and earlier).
boolean-datetime / W1502 also only applies to dead versions of Python (3.4 and earlier).
bad-indentation / W0311 is implemented by E111 and the pylint example gives a true positive with this configuration:
```
[tool.ruff]
select = ["E111"]
```
compare-to-empty-string / C1901 has been renamed to use-implicit-booleaness-not-comparison-to-string / C1804.
compare-to-zero / C2001 has been renamed to use-implicit-booleaness-not-comparison-to-zero / C1805.
consider-using-f-string / C0209 is implemented by UP031 + UP032.

(I combined the other comments into this one, sorry for noise).

Answer 95 · 2023-05-27T13:39:59.000Z

Note: bad-indentation / W0311 is implemented by E111 and the pylint example gives a true positive with this configuration:

[tool.ruff]
select = ["E111"]

Answer 96 · 2023-05-27T13:44:45.000Z

Note: boolean-datetime / W1502 also only applies to dead versions of Python (3.4 and earlier).

Answer 97 · 2023-05-27T15:51:57.000Z

Note: unknown-option-value / W0012 probably shouldn't be implemented either, as it's specific to pylint error codes.

Answer 98 · 2023-05-27T16:55:44.000Z

I've went through and evaluated all the rules listed here that aren't yet implemented (see the previous comment for some other findings), to try and find out which rules are redundant when using mypy. Mostly this was to find out what value Pylint brings that isn't already covered by the combination of ruff + mypy, but I think this could also be useful to ruff developers when prioritizing which of the rules listed to work on.

There was one rule that is partially implemented in mypy, because Pylint seems to have its own semantics for what to consider an abstract method:

abstract-method

I found these rules to have an equivalent error in mypy:

abstract-class-instantiated
arguments-differ
assigning-non-slot
assignment-from-no-return
assignment-from-none
bad-exception-cause
bad-format-character
bad-reversed-sequence
bad-super-call
bad-thread-instantiation
catching-non-exception
comparison-with-callable
deprecated-class
dict-iter-missing-items
format-combined-specification
global-variable-undefined
import-error
inconsistent-mro
inherit-non-class
init-is-generator
invalid-class-object
invalid-enum-extension
invalid-envvar-value
invalid-format-returned
invalid-hash-returned
invalid-metaclass
invalid-overridden-method
invalid-repr-returned
invalid-sequence-index
invalid-slice-index
invalid-slots-object
invalid-slots
invalid-star-assignment-target
invalid-str-returned
invalid-unary-operand-type
invalid-unicode-codec
isinstance-second-argument-not-valid-type
method-hidden
misplaced-format-function
missing-format-argument-key
missing-format-attribute
missing-kwoa
missing-type-doc
missing-yield-type-doc
no-member
no-value-for-parameter
non-iterator-returned
non-str-assignment-to-dunder-name
nonlocal-and-global
not-a-mapping
not-an-iterable
not-async-context-manager
not-callable
not-context-manager
overridden-final-method
raising-bad-type
raising-non-exception
redefined-variable-type
redundant-keyword-arg
relative-beyond-top-level
self-cls-assignment
signature-differs
star-needs-assignment-target
subclassed-final-class
super-without-brackets
too-many-function-args
typevar-double-variance
typevar-name-mismatch
unbalanced-dict-unpacking
unbalanced-tuple-unpacking
unexpected-keyword-arg
unhashable-member
unpacking-non-sequence
unsubscriptable-object
unsupported-assignment-operation
unsupported-binary-operation
unsupported-delete-operation
unsupported-membership-test
used-before-assignment
using-final-decorator-in-unsupported-version
wrong-exception-operation

I didn't evaluate these rules:

deprecated-argument
invalid-character-carriage-return
invalid-characters-in-docstring

And I found these shouldn't be implemented for various reasons, see previous comment:

boolean-datetime
return-arg-in-generator
unknown-option-value
using-f-string-in-unsupported-version

I hope this is useful. Here's a repository with my categorizations, should someone be interested in the details: https://github.com/antonagestam/pylint-mypy-overlap

Answer 99 · 2023-05-28T14:45:16.000Z

This PR also implements one of the rules for FixMe comments (W0511): #4681

Answer 100 · 2023-05-29T16:35:14.000Z

I'm looking into unnecessary-ellipsis ~~and unnecessary-pass~~.

Edit: unnecessary-ellipsis is partially covered by ellipsis-in-non-empty-class-body

Implement Pylint

Error

Warning

Convention

Refactor