Implement Pylint

Error

[ ] abstract-class-instantiated / E0110
[ ] access-member-before-definition / E0203
[ ] assigning-non-slot / E0237
[ ] assignment-from-no-return / E1111
[ ] assignment-from-none / E1128
[x] await-outside-async / E1142 (PLE1142)
[x] ~bad-configuration-section / E0014~
[ ] bad-except-order / E0701
[ ] bad-exception-cause / E0705
[ ] bad-format-character / E1300
[x] ~bad-plugin-value / E0013~
[ ] bad-reversed-sequence / E0111
[x] bad-str-strip-call / E1310 (PLE1310)
[x] bad-string-format-type / E1307 (PLE1307)
[ ] bad-super-call / E1003
[x] bidirectional-unicode / E2502 (PLE2502)
[x] ~broken-collections-callable / E6005~
[x] ~broken-noreturn / E6004~
[ ] catching-non-exception / E0712
[ ] class-variable-slots-conflict / E0242
[x] continue-in-finally / E0116 (PLE0116)
[ ] dict-iter-missing-items / E1141
[x] ~duplicate-argument-name / E0108~
[x] duplicate-bases / E0241 (PLE0241)
[x] format-needs-mapping / E1303 (F502)
[x] function-redefined / E0102 (F811)
[ ] import-error / E0401
[ ] inconsistent-mro / E0240
[ ] inherit-non-class / E0239
[ ] init-is-generator / E0100
[x] invalid-all-format / E0605 (PLE0605)
[x] invalid-all-object / E0604 (PLE0604)
[ ] invalid-bool-returned / E0304
[ ] invalid-bytes-returned / E0308
[x] invalid-character-backspace / E2510 (PLE2510)
[ ] invalid-character-carriage-return / E2511
[x] invalid-character-esc / E2513 (PLE2513)
[x] invalid-character-nul / E2514 (PLE2514)
[x] invalid-character-sub / E2512 (PLE2512)
[x] invalid-character-zero-width-space / E2515 (PLE2515)
[ ] invalid-class-object / E0243
[ ] invalid-enum-extension / E0244
[ ] invalid-envvar-value / E1507
[ ] invalid-format-returned / E0311
[ ] invalid-getnewargs-ex-returned / E0313
[ ] invalid-getnewargs-returned / E0312
[ ] invalid-hash-returned / E0309
[ ] invalid-index-returned / E0305
[ ] invalid-length-hint-returned / E0310
[ ] invalid-length-returned / E0303
[ ] invalid-metaclass / E1139
[ ] invalid-repr-returned / E0306
[ ] invalid-sequence-index / E1126
[ ] invalid-slice-index / E1127
[ ] invalid-slice-step / E1144
[ ] invalid-slots / E0238
[ ] invalid-slots-object / E0236
[ ] invalid-star-assignment-target / E0113
[ ] invalid-str-returned / E0307
[ ] invalid-unary-operand-type / E1130
[ ] invalid-unicode-codec / E2501
[ ] logging-format-truncated / E1201
[x] logging-too-few-args / E1206 (PLE1206)
[x] logging-too-many-args / E1205 (PLE1205)
[ ] logging-unsupported-format / E1200
[ ] method-hidden / E0202
[x] misplaced-bare-raise / E0704 (PLE0704)
[ ] misplaced-format-function / E0119
[x] missing-format-string-key / E1304  (F524)
[ ] missing-kwoa / E1125
[x] mixed-format-string / E1302 (F506)
[ ] modified-iterating-dict / E4702
[ ] modified-iterating-set / E4703
[ ] no-member / E1101
[x] no-method-argument / E0211 (N805)
[ ] no-name-in-module / E0611
[x] no-self-argument / E0213 (N805)
[ ] no-value-for-parameter / E1120
[ ] non-iterator-returned / E0301
[x] nonexistent-operator / E0107 (B002)
[ ] nonlocal-and-global / E0115
[x] nonlocal-without-binding / E0117 (PLE0117)
[ ] not-a-mapping / E1134
[ ] not-an-iterable / E1133
[ ] not-async-context-manager / E1701
[ ] not-callable / E1102
[ ] not-context-manager / E1129
[x] not-in-loop / E0103 (F701, F702)
[x] notimplemented-raised / E0711 (F901)
[ ] potential-index-error / E0643
[ ] raising-bad-type / E0702
[ ] raising-non-exception / E0710
[ ] redundant-keyword-arg / E1124
[x] relative-beyond-top-level / E0402 (TID252)
[ ] repeated-keyword / E1132
[x] ~return-arg-in-generator / E0106~
[x] return-in-init / E0101 (PLE0101)
[x] return-outside-function / E0104 (F706)
[ ] singledispatch-method / E1519
[ ] singledispatchmethod-function / E1520
[ ] star-needs-assignment-target / E0114
[x] syntax-error / E0001 (E999)
[x] too-few-format-args / E1306 (F524)
[x] too-many-format-args / E1305 (F522)
[ ] too-many-function-args / E1121
[x] too-many-star-expressions / E0112 (F622)
[x] truncated-format-string / E1301 (F501)
[x] undefined-all-variable / E0603 (F822)
[x] undefined-variable / E0602 (F821)
[ ] unexpected-keyword-arg / E1123
[x] unexpected-special-method-signature / E0302 (PLE0302)
[ ] unhashable-member / E1143
[ ] unpacking-non-sequence / E0633
[ ] unsubscriptable-object / E1136
[ ] unsupported-assignment-operation / E1137
[ ] unsupported-binary-operation / E1131
[ ] unsupported-delete-operation / E1138
[ ] unsupported-membership-test / E1135
[ ] used-before-assignment / E0601
[x] used-prior-global-declaration / E0118 (PLE0118)
[x] yield-inside-async-function / E1700 (PLE1700)
[x] yield-outside-function / E0105 (F704)

Warning

[ ] abstract-method / W0223
[x] anomalous-backslash-in-string / W1401 (W605)
[ ] anomalous-unicode-escape-in-string / W1402
[ ] arguments-differ / W0221
[ ] arguments-out-of-order / W1114
[ ] arguments-renamed / W0237
[x] assert-on-string-literal / W0129 (PLW0129)
[x] assert-on-tuple / W0199 (F631)
[ ] attribute-defined-outside-init / W0201
[ ] bad-builtin / W0141
[x] bad-dunder-name / W3201 (PLW3201)
[x] bad-format-string / W1302
[x] bad-format-string-key / W1300
[ ] bad-indentation / W0311
[ ] bad-open-mode / W1501
[ ] bad-staticmethod-argument / W0211
[ ] bad-thread-instantiation / W1506
[x] bare-except / W0702 (E722)
[x] binary-op-exception / W0711 (PLW0711)
[x] ~boolean-datetime / W1502~
[x] broad-exception-caught / W0718
[ ] broad-exception-raised / W0719
[x] cell-var-from-loop / W0640 (B023)
[ ] comparison-with-callable / W0143
[ ] confusing-with-statement / W0124
[x] consider-ternary-expression / W0160 (SIM108)
[x] dangerous-default-value / W0102 (B006)
[ ] deprecated-argument / W4903
[ ] deprecated-class / W4904
[ ] deprecated-decorator / W4905
[ ] deprecated-method / W4902
[ ] deprecated-module / W4901
[ ] deprecated-typing-alias / W6001
[ ] differing-param-doc / W9017
[ ] differing-type-doc / W9018
[x] duplicate-except / W0705 (B014)
[x] duplicate-key / W0109 (F601)
[x] duplicate-string-formatting-argument / W1308
[x] duplicate-value / W0130 (B033)
[x] eq-without-hash / W1641 (PLW1641)
[x] eval-used / W0123 (PGH001)
[x] exec-used / W0122 (S102)
[x] expression-not-assigned / W0106 (B018)
[x] f-string-without-interpolation / W1309 (F541)
[x] fixme / W0511 (FIX001, FIX002, FIX003, FIX004)
[x] forgotten-debug-statement / W1515 (T100 )
[x] format-combined-specification / W1305 (F525)
[x] format-string-without-interpolation / W1310 (F541)
[ ] global-at-module-level / W0604
[x] global-statement / W0603 (PLW0603)
[x] global-variable-not-assigned / W0602 (PLW0602)
[ ] global-variable-undefined / W0601
[x] implicit-str-concat / W1404 (ISC001)
[x] import-self / W0406 (PLW0406)
[x] inconsistent-quotes / W1405 (Q000)
[x] invalid-envvar-default / W1508 (PLW1508)
[ ] invalid-format-index / W1307
[ ] invalid-overridden-method / W0236
[ ] isinstance-second-argument-not-valid-type / W1116
[x] keyword-arg-before-vararg / W1113 (B026)
[x] logging-format-interpolation / W1202 (G)
[x] logging-fstring-interpolation / W1203 (G)
[x] logging-not-lazy / W1201 (G)
[x] lost-exception / W0150 (B012)
[ ] method-cache-max-size-none / W1518
[x] misplaced-future / W0410 (F404)
[ ] missing-any-param-doc / W9021
[x] missing-format-argument-key / W1303 (F524)
[ ] missing-format-attribute / W1306
[ ] missing-param-doc / W9015
[ ] missing-parentheses-for-call-in-test / W0126
[ ] missing-raises-doc / W9006
[ ] missing-return-doc / W9011
[ ] missing-return-type-doc / W9012
[ ] missing-timeout / W3101
[ ] missing-type-doc / W9016
[ ] missing-yield-doc / W9013
[ ] missing-yield-type-doc / W9014
[ ] modified-iterating-list / W4701
[ ] multiple-constructor-doc / W9005
[x] named-expr-without-context / W0131 (PLW0131)
[ ] nan-comparison / W0177
[x] nested-min-max / W3301 (PLW3301)
[x] non-ascii-file-name / W2402 (N999)
[ ] non-parent-init-called / W0233
[ ] non-str-assignment-to-dunder-name / W1115
[ ] overlapping-except / W0714
[ ] overridden-final-method / W0239
[x] pointless-statement / W0104 (B018)
[ ] pointless-string-statement / W0105
[ ] possibly-unused-variable / W0641
[ ] preferred-module / W0407
[ ] protected-access / W0212
[x] raise-missing-from / W0707 (TRY200)
[ ] raising-format-tuple / W0715
[ ] redeclared-assigned-name / W0128
[x] redefined-builtin / W0622 (A001)
[x] redefined-loop-name / W2901 (PLW2901)
[ ] redefined-outer-name / W0621
[ ] redefined-slots-in-subclass / W0244
[ ] redundant-returns-doc / W9008
[ ] redundant-u-string-prefix / W1406
[ ] redundant-unittest-assert / W1503
[ ] redundant-yields-doc / W9010
[x] reimported / W0404 (F811)
[x] self-assigning-variable / W0127 (PLW0127)
[ ] self-cls-assignment / W0642
[ ] shallow-copy-environ / W1507
[ ] signature-differs / W0222
[ ] subclassed-final-class / W0240
[x] subprocess-popen-preexec-fn / W1509 (PLW1509)
[x] subprocess-run-check / W1510 (PLW1510)
[ ] super-init-not-called / W0231
[ ] super-without-brackets / W0245
[ ] too-many-try-statements / W0717
[x] try-except-raise / W0706 (TRY302)
[ ] unbalanced-dict-unpacking / W0644
[ ] unbalanced-tuple-unpacking / W0632
[ ] undefined-loop-variable / W0631
[x] ~unknown-option-value / W0012~
[ ] unnecessary-ellipsis / W2301
[x] unnecessary-lambda / W0108 (PLW0108)
[x] unnecessary-pass / W0107 (PIE790)
[x] unnecessary-semicolon / W0301 (E703)
[ ] unreachable / W0101
[x] unspecified-encoding / W1514 (PLW1514)
[x] unused-argument / W0613 (ARG001)
[x] unused-format-string-argument / W1304 (F507)
[x] unused-format-string-key / W1301 (F504)
[x] unused-import / W0611 (F401)
[ ] unused-private-member / W0238
[x] unused-variable / W0612 (F841)
[ ] unused-wildcard-import / W0614
[x] useless-else-on-loop / W0120 (PLW0120)
[ ] useless-param-doc / W9019
[ ] useless-parent-delegation / W0246
[ ] useless-type-doc / W9020
[ ] useless-with-lock / W2101
[ ] using-constant-test / W0125
[x] ~using-f-string-in-unsupported-version / W2601~
[ ] using-final-decorator-in-unsupported-version / W2602
[ ] while-used / W0149
[x] wildcard-import / W0401 (F403)
[ ] wrong-exception-operation / W0716

Convention

[x] bad-classmethod-argument / C0202 (`N804)
[x] bad-docstring-quotes / C0198 (Q002)
[ ] bad-file-encoding / C2503
[ ] bad-mcs-classmethod-argument / C0204
[ ] bad-mcs-method-argument / C0203
[x] compare-to-empty-string / C1901 (PLC1901)
[ ] compare-to-zero / C2001
[x] consider-iterating-dictionary / C0201 (SIM118)
[x] consider-using-any-or-all / C0501 (SIM110, SIM111)
[ ] consider-using-dict-items / C0206
[ ] consider-using-enumerate / C0200
[ ] consider-using-f-string / C0209
[ ] dict-init-mutate / C3401
[ ] disallowed-name / C0104
[x] docstring-first-line-empty / C0199 (D210)
[x] empty-docstring / C0112 (D419)
[ ] import-outside-toplevel / C0415
[ ] import-private-name / C2701
[ ] invalid-characters-in-docstring / C0403
[x] invalid-name / C0103 (N815)
[x] line-too-long / C0301 (E501)
[x] misplaced-comparison-constant / C2201 (SIM300)
[x] missing-class-docstring / C0115 (D101)
[x] missing-final-newline / C0304 (W292)
[x] missing-function-docstring / C0116 (D103)
[x] missing-module-docstring / C0114 (D100)
[ ] mixed-line-endings / C0327
[x] multiple-imports / C0410 (E401)
[x] multiple-statements / C0321 (E701, E702)
[x] non-ascii-module-import / C2403 (PLC2403)
[x] non-ascii-name / C2401 (PLC2401)
[x] single-string-used-for-slots / C0205 (PLC0205)
[x] singleton-comparison / C0121 (E711 , E712)
[] superfluous-parens / C0325
[ ] too-many-lines / C0302
[ ] trailing-newlines / C0305
[ ] trailing-whitespace / C0303
[x] typevar-double-variance / C0131 (PLC0131)
[x] typevar-name-incorrect-variance / C0105 (PLC0105)
[x] typevar-name-mismatch / C0132 (PLC0132)
[ ] unexpected-line-ending-format / C0328
[x] ungrouped-imports / C0412 (I001)
[x] unidiomatic-typecheck / C0123 (E721)
[x] unnecessary-direct-lambda-call / C3002
[ ] unnecessary-dunder-call / C2801
[x] unnecessary-lambda-assignment / C3001
[x] unneeded-not / C0113 (SIM208)
[ ] use-implicit-booleaness-not-comparison / C1803
[ ] use-implicit-booleaness-not-len / C1802
[ ] use-maxsplit-arg / C0207
[x] use-sequence-for-iteration / C0208 (PLC0208)
[x] useless-import-alias / C0414 (PLC0414)
[x] wrong-import-order / C0411 (I001)
[x] wrong-import-position / C0413 (E402 )
[ ] wrong-spelling-in-comment / C0401
[ ] wrong-spelling-in-docstring / C0402

Refactor

[ ] chained-comparison / R1716
[x] comparison-of-constants / R0133 (PLR0133)
[x] comparison-with-itself / R0124 (PLR0124)
[ ] condition-evals-to-constant / R1727
[ ] confusing-consecutive-elif / R5601
[x] consider-alternative-union-syntax / R6003 (UP007)
[x] consider-merging-isinstance / R1701 (PLR1701)
[ ] consider-swap-variables / R1712
[x] consider-using-alias / R6002 (UP006)
[ ] consider-using-assignment-expr / R6103
[ ] consider-using-augmented-assign / R6104
[x] consider-using-dict-comprehension / R1717 (C402)
[ ] consider-using-from-import / R0402
[x] consider-using-generator / R1728 (C417)
[x] consider-using-get / R1715 (SIM401)
[x] consider-using-in / R1714
[ ] consider-using-join / R1713
[ ] consider-using-max-builtin / R1731
[ ] consider-using-min-builtin / R1730
[ ] consider-using-namedtuple-or-dataclass / R6101
[x] consider-using-set-comprehension / R1718 (C401)
[x] consider-using-sys-exit / R1722 (PLR1722)
[x] consider-using-ternary / R1706 (PLR1706 )
[ ] consider-using-tuple / R6102
[ ] consider-using-with / R1732
[ ] cyclic-import / R0401
[ ] duplicate-code / R0801
[x] else-if-used / R5501 (PLR5501)
[ ] empty-comment / R2044
[x] inconsistent-return-statements / R1710 (RET501, RET502)
[x] literal-comparison / R0123 (F632)
[x] magic-value-comparison / R2004 (PLR2004)
[ ] no-classmethod-decorator / R0202
[x] no-else-break / R1723 (RET508)
[x] no-else-continue / R1724 (RET507)
[x] no-else-raise / R1720 (RET506)
[x] no-else-return / R1705 (RET505)
[x] no-self-use / R6301 (PLR6301)
[ ] no-staticmethod-decorator / R0203
[x] property-with-parameters / R0206 (PLR0206)
[ ] redefined-argument-from-local / R1704
[ ] redefined-variable-type / R0204
[ ] simplifiable-condition / R1726
[ ] simplifiable-if-expression / R1719
[ ] simplifiable-if-statement / R1703
[ ] simplify-boolean-expression / R1709
[ ] stop-iteration-return / R1708
[x] super-with-arguments / R1725 (UP008)
[x] too-complex / R1260 (C901)
[ ] too-few-public-methods / R0903
[ ] too-many-ancestors / R0901
[x] too-many-arguments / R0913 (PLR0913)
[x] too-many-boolean-expressions / R0916 (PLR0916)
[x] too-many-branches / R0912 (PLR0912)
[ ] too-many-instance-attributes / R0902
[ ] too-many-locals / R0914
[ ] too-many-nested-blocks / R1702
[x] too-many-public-methods / R0904 (PLR0904)
[x] too-many-return-statements / R0911 (PLR0911)
[x] too-many-statements / R0915 (PLR0915)
[x] trailing-comma-tuple / R1707 (COM818)
[x] unnecessary-comprehension / R1721 (C416)
[ ] unnecessary-dict-index-lookup / R1733
[ ] unnecessary-list-index-lookup / R1736
[x] use-a-generator / R1729 (C417)
[x] use-dict-literal / R1735 (C406)
[x] use-list-literal / R1734 (C405)
[x] use-set-for-membership / R6201 (PLR6201)
[x] useless-object-inheritance / R0205 (UP004)
[x] ~useless-option-value / R0022~
[x] useless-return / R1711 (PLR1711)

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. But then we have to support four-digit codes, as opposed to our current three-digit codes.

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

I'll work on unneeded-not this weekend.

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.

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

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

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

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

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.

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: https://github.com/python/mypy/issues/6251).

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

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.

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?

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?

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.

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?

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.

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

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

this is covered in https://github.com/charliermarsh/ruff/issues/1203

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

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

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

Thank you! Gonna remove them from the list altogether.

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

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

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

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

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.

@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}.")

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

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

@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 :)

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

The pylint rules implemented by PyCharm: https://github.com/charliermarsh/ruff/issues/2972

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: https://github.com/charliermarsh/ruff/issues/3040

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?

I'll do invalid-character-*

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

W0123 is an overlap of PHG001, so I guess that could be ticket off?

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.

@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

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

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

:thumbsup: 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.

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?

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.

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

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 anExportMap 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. Which (by the way) was easily broken a bit later on: https://github.com/pylint-dev/pylint/issues/7399.
I will gladly help if I can.

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

Can RustPython make a very small interpreter enough to import names?
The import rules of python are very complicated and depending on huge python library importlib.

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.

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

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

Why do you think that is necessarily true? Have you read https://github.com/charliermarsh/ruff/issues/970#issuecomment-1516569335?

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.

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'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

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

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.

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

@chanman3388 - Thankfully we already handle alias tracking properly and it's abstracted away, for the most part. 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.)

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

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.

E0102 seems to be already covered by pyflakes F811?

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

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.

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?

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

cool,
taking a look at E0112 than

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

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.

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

I'll take a look at W0130.

W0706 is already implemented as TRY302.

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?

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

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 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 take a look at the merged issues higher up for what these look like. I hope that answers your question!

Thanks, that helps! Raised https://github.com/charliermarsh/ruff/pull/4532

W707 is an alias for TRY200

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

I am looking into E1111

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

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

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

Note: return-arg-in-generator/E0106 probably should not be implemented as it only applies to dead versions of Python (3.3 and earlier).

Note: bad-indentation / W0311 is implemented by E111 and the pylint example gives a true positive with this configuration:
[tool.ruff]
select = ["E111"]

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

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

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

This PR also implements one of the rules for FixMe comments: https://github.com/charliermarsh/ruff/pull/4681

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

@hoel-bagard those would most probably already be detected by flake8 lints.

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

unnecessary-passis detected with Flake8-pie (PIE):
PIE790 	unnecessary-pass 	Unnecessary pass statement

W0130 is now also flake8-bugbear B033 as flake8-bugbear has implemented it too in their most recent release.

Oh nice. I will move it to bugbear and alias it.

general question regarding direction of ruff: it seems a lot of these pylint errors are related to typechecking which may overlap with a type checker such as mypy or pyre. Wondering if Ruff plans to become a type checker or intend to stay a linter? (Mainly asking as pyre is rather slow and I fear AST type checking may also slow ruff down in the long run?)

pylint is doing some limited type checking for historical reason (as it started 20 years ago when no type checkers were available). We're not implementing type checking in 2023 because mypy and pyright happened and we would not re-implement those checks again if we had too. I think they would bring no value if they were implemented in ruff -- and we're also considering removing them from pylint. But unfortunately I don't have an exhaustive list of them to give, I always use the same invalid-envvar-value as an example :)

Aww, I find those rules quite valuable for untyped/partially typed codebase. While I'd love to have all codebases be fully typed code I work on often was started before typing and is in partial state of typed. Or libraries we import are untyped and pylint can still type issues that type checker can't. I think python ecosystem for top 100ish libraries is like 30-40% typed today. Still long way to go there and I'm unsure less popular libraries are more/less typed.
If your codebase is fully typed then I would agree that mypy/pyright/etc are generally better choice then type lint rules in non type checker.

Don't worry we're not throwing inference away any time soon :) Pylint checks like invalid-envvar-value though are checking the type of a particular argument of a particular function in the stdlib (i.e. it's already typed for everyone). mypy detect it generically at no cost for them and ruff would also detect it if if it become a type checker.

W0150 is implemented as jump-statement-in-finally (B012).

We're not implementing type checking in 2023 because mypy and pyright happened and we would not re-implement those checks again if we had too. I think they would bring no value if they were implemented in ruff -- and we're also considering removing them from pylint.

It might make sense to move the rules which require type-checking to a separate section.

Yeah, I need to do a pass over this issue to make it more useful / actionable based on @antonagestam's excellent analysis.

@charliermarsh while pylint and mypy lints may have significant overlap, do note that mypy can only effectively catch these problems if the given code is properly type hinted. pylint however works with zero type hints.
Using both mypy and ruff for example, can probably cover the vast majority of pylint issues, but that would only work for users that have fully type checked code.

@Igetin The problem here is that any variables coming from function parameters will never be inferred or checked, for example. mypy without type hints is really not that useful.

Rules

no-else-break / R1723,
no-else-continue / R1724,
no-else-raise / R1720,
and no-else-return / R1705

are all implemented as RET508, RET507, RET506, RET505 respectively.

broad-exception-raised (W0719) has been implemented as raise-vanilla-class (TRY002)

I'm implementing PLE0243

It looks like W0107 is already implement (Derived from the flake8-pie linter). Can we check that one?

I'm implementing PLW3201

I'm implementing PLR0913

I'm implementing PLR6301

I ported the script of @cidrblock to run [interactively][https://trinket.io/embed/python3/76efaf1927) without setting up a local env.

That's really cool, thank you both!

I'm implementing PLC2401

[ ] broad-exception-raised / W0719

Isn't this covered by TRY002? doc: https://beta.ruff.rs/docs/rules/raise-vanilla-class/

Don't want to be "that guy" as I'm sure this list is a bit of a nightmare to maintain, but there are a few entries on this list which are claimed to be done, but don't have an assigned code, nor do they appear in the docs.
(I've been doing some initial investigation for my work in an aim to migrate from Pylint to Ruff, hence the combing lmao.)
Implemented rules missing codes:

W1302
W1300
W0718
W1308
W1310
R1714

I also compiled a list of rules with a code in the docs, but not in the issue body:

E0302 (PLE0302)
W0130 (B033)
W1310 (potentially F541?)
W3301 (PLW3301)
W0107 (PIE790)
R0913 (PLR0913)
R1721 (C416)

Been following this for a while. Glad to see the good work continuing!

Pylint has a number of configuration options that are not (yet) available in ruff.
In my case I want to add "good" dunder name (__html__), this is possible using the good-dunder-names option in pylint. I cannot find such an option for ruff, so either disabling the rule or noqa'ing each occurrence is the only option for now.

@parafoxia R1714 is implemented as PLR1714 in Ruff, though you might be right about the rest.

@parafoxia R1714 is implemented as PLR1714 in Ruff, though you might be right about the rest.

Ah, thanks!

Since there probably are pylintistas in this issue, linking my tool: https://github.com/akx/pylint-to-ruff (It actually reads this issue to figure out what's been implemented in Ruff...)

Working on simplify-boolean-expression / R1709
but seems there's a wrong status in the table.
R1706 is marked as done by SIM108 but they are somewhat different.
R1706
https://pylint.pycqa.org/en/latest/user_guide/messages/refactor/consider-using-ternary.html
# before
x, y = 1, 2
maximum = x >= y and x or y  # [consider-using-ternary]

# after
x, y = 1, 2
`maximum = x if x >= y else y`

SIM108
https://docs.astral.sh/ruff/rules/if-else-block-instead-of-if-exp/
# before
if foo:
    bar = x
else:
    bar = y

# after
bar = x if foo else y

R1706 can be implemented in line with R1709, so have plan to do it together.
Please review and confirm it. Thank you.

@danbi2990 - Ah, that makes sense. I'm fine to have R1706 implemented separately in that case.
The only issue with R1709 is that it seems to have some overlap with https://docs.astral.sh/ruff/rules/expr-and-false/.

Ok, R1706 is in progress.
For R1709,
Below difference exists which seems trivial.
If you think it's unnecessary, only R1706 will be PRed.
# before
'apple' and False or 'orange'

# after expr-and-false (SIM223)
False or 'orange'

# after R1709
'orange'

Hi, is there any plans for implementing the pylint extensions?

[ ]  reimported / W0404

i think this is covered by redefined-while-unused (F811)

Working on redefined-argument-from-local / R1704

unspecified-encoding / W1514 would also cover for flake8-file-encoding

FYI, UP034 does not implement C0325 and should be unmarked as done. See: https://github.com/astral-sh/ruff/issues/2389#issuecomment-1762006600 (and the full thread) for more details

(I went ahead and unchecked it.)

i think relative-beyond-top-level is covered by TID252

Looks like compare-to-zero / C2001 has been removed from pylint in favor of use-implicit-booleaness-not-comparison-to-zero / C1805
Nice and terse.

How did you guys manage to get all the hype, with only 20% of the checkboxes?

@flavius in my experience there's two camps of people: flake8 and flake8 plugin users, and pylint users. Ruff currently successfully caters to the first, and a small number of second.

How did you guys manage to get all the hype, with only 20% of the checkboxes?

Among other things, Ruff with mypy covers a significant portion of the not yet implemented Pylint rules.

Mypy is a different thing altogether as it requires your and your dependencies to have correct type hints, ruff and pylint don't.

There are some pretty good reasons to switch from pylint only to ruff + pylint, even with the current set of implemented checks: shorter overall linting duration, fast feedback loop on a large percentage of the most useful checks, some checks that pylint doesn't have, etc.  I wrote up the rationale in our case on https://github.com/openedx/edx-platform/issues/32174 ; we just started the switch so I don't have numbers yet, but it's looking pretty promising so far.

Mypy is a different thing altogether as it requires your and your dependencies' code to have correct type hints, ruff and pylint don't.

That's true! If a user both wants the above missing Pylint rules and doesn't want to use and facilitate a type checker like mypy, then they probably shouldn't replace Pylint with Ruff. I just think it's relevant because many of the missing rules are not implemented as

they require a more sophisticated type inference system than Ruff (or flake8 for that matter),
they were designed before the widespread acceptance of type checking and annotation, so implement checks that would now be considered the remit of a type checker cf. a linter (for example, no-member/E1101).

This, personally, is why I have been happy to replace Pylint with Ruff despite it missing many of its rules.

Since mypy is about as slow as pylint, it would be nice if ruff replaced it too (#3893)

Since mypy is about as slow as pylint, it would be nice if ruff replaced it too (#3893)

Have you tried dmypy https://mypy.readthedocs.io/en/stable/mypy_daemon.html?

Yeah, but it's barely any faster in my experience

Maybe I sounded offensive, but my question was honest: how?
If I did this project, I would have gotten maybe 10 occasional users.

@flavius Yeah, your tone didn't really convey 😅
"At this stage"? Ruff has been available for more than a year now (though admittedly the old versions are much, pun intended, ruffer than what we have now).
Also, developers do care about their DX, and Ruff delivers on that: even if the (Pylint or otherwise) rule coverage isn't 100%, or say, even 50%, getting practically instant results on large codebases is a much bigger win for most, which certainly drove (and drives) adoption.
There's also the fact that the Ruff team has one of the most inclusive and friendly attitudes towards contributions I've seen in OSS in a while; if a rule is missing, and it's not thoroughly silly, you can go ahead and implement it.
Then, of course, there's a bit of marketing and luck involved :)

Maybe I sounded offensive, but my question was honest: how?

As tusharsadhwani said, there are a lot of users who make heavy use of MyPy type annotations and don't feel much need for PyLint because of it.
(eg. These days, I use Python because Rust has no PyQt/PySide or Django, I do a "backend in Rust, frontend in Python, glued together with PyO3" configuration where feasible (eg. using Python as "QML for QWidget GUIs" in a Rust+PyQt app) , and it saddens me that, even in strict mode and with type annotations applied liberally, MyPy is nowhere near as strong a guarantee of code function as Rust would be.)

@DetachHead I've never used it as I've only really just heard of it myself, but Pylyzer is a Mypy and Pyright alternative written in Rust, so may be worth checking out if you're looking for something like that. I think it's still in alpha itself though, and is one of those projects that makes very bold subjective claims as objective fact, so make of that what you will I spose lmao.

Maybe I sounded offensive, but my question was honest: how?

ruff was not originally a replacement for pylint, black or mypy: it was a replacement for flake8. You can use pylint + ruff but a lot of flake8 users were not using pylint to begin with. ruff is faster than flake8, it had more feature than flake8 from the get go, it has autofix, and is more contributor friendly than flake8 (ruff has "pyproject.toml support" listed as the 3rd selling point in 2023, because flake8's maintainers vehemently refuse(d?) to support it, and ban on sight those asking for it). ruff was optimized for speed but also for adoption : everything was done for an easy transition from flake8 to ruff.  If you can replace one open-source package by another open source package easily and it's 20 time faster, with feature parity + autofix + some, and with a friendly and reactive maintainer working full time on it, the migration is going to be an easy choice.

For me, the reason I'm so excited about Ruff is:

The maintainer friendliness that Pierre mentioned--they respond to issues in such a kind and open-minded way.  This is the biggest indicator to me that a project will have longevity and success because this is the kind of projects that attracts talented people to help out.
The trajectory they're on.  I don't think it's "20% of the checkboxes"; it's like 50% at this point?  And it's all happened incredibly quickly.  So as a user, it's easy to imagine that they'll be at 90% pretty soon.  (In fairness, they've been able to do this in part by building on the hard work of other linters like Pylint that have come up with lists of useful rules, but that's the beauty of open source.  I'm not sure if they share test cases for the rules too?)
The fast feedback loop that Jeremy mentioned.  It makes development a lot faster and more painless.

(As for MyPy speed, what I do is run Ruff and PyRight really often, and then I run Pylint and MyPy before committing changes.)

I think the single most useful post in this PR is this one, from the pylint maintainer:
https://github.com/astral-sh/ruff/issues/970#issuecomment-1585522741

pylint is doing some limited type checking for historical reason (as it started 20 years ago when no type checkers were available). We're not implementing type checking in 2023 because mypy and pyright happened and we would not re-implement those checks again if we had too. I think they would bring no value if they were implemented in ruff -- and we're also considering removing them from pylint. But unfortunately I don't have an exhaustive list of them to give, I always use the same invalid-envvar-value as an example :)

It's been completely lost in the noise by now, but it's worth repeating.
The ruff FAQ also states pretty clearly:

It's recommended that you use Ruff in conjunction with a type checker, like Mypy, Pyright, or Pyre, with Ruff providing faster feedback on lint violations and the type checker providing more detailed feedback on type errors.

https://docs.astral.sh/ruff/faq/#how-does-ruff-compare-to-mypy-or-pyright-or-pyre
I buy into this logic and I personally hope that ruff won't implement the entire set of pylint rules.

Even with the low overall coverage of current Pylint rules, what Ruff has implemented already is still covering a majority of the issues I care about.
I think it's completely fair to scrutinize the options in this list that are better-covered by a different tool, like Mypy. You can't make this tool do everything, or it will become a bloated and unmaintainable mess within 5 years.
I would go as far as to suggest that some of the auto-fixing, import sorting, and code formatting could just be gutted: they have their own dedicated tools that cover the concerns. Ruff would be well-suited as a linter to replace other linters, while working well in concert with other tools like isort, black, and mypy.
From where things are today, I would say take the rules that have overlap with mypy, and just mark them wontfix. Other tools exist, will continue to exist, and are more focused on covering these concerns: Ruff does not have to reinvent everything.

Thanks for the support everyone <3
If someone wants to compile a list of unimplemented Pylint rules that are covered by mypy (preferably with references to the type checking rule that replaces it), I will update the list.

(As for MyPy speed, what I do is run Ruff and PyRight really often, and then I run Pylint and MyPy before committing changes.)

I run ruff and MyPy on save and it happens asynchronously... that doesn't change the fact that I block on MyPy frequently and whether I'm manually waiting for Vim to update the quickcheck pane after typing :w or a Yakuake tab to update after running some kind of pre-commit check script doesn't make a significant different to the fact that I'm blocking on MyPy being slow.

Thanks for the support everyone <3
If someone wants to compile a list of unimplemented Pylint rules that are covered by mypy (preferably with references to the type checking rule that replaces it), I will update the list.

There was a comment from earlier this year that listed some rules.

Even with the low overall coverage of current Pylint rules, what Ruff has implemented already is still covering a majority of the issues I care about.
I think it's completely fair to scrutinize the options in this list that are better-covered by a different tool, like Mypy. You can't make this tool do everything, or it will become a bloated and unmaintainable mess within 5 years.
I would go as far as to suggest that some of the auto-fixing, import sorting, and code formatting could just be gutted: they have their own dedicated tools that cover the concerns. Ruff would be well-suited as a linter to replace other linters, while working well in concert with other tools like isort, black, and mypy.
From where things are today, I would say take the rules that have overlap with mypy, and just mark them wontfix. Other tools exist, will continue to exist, and are more focused on covering these concerns: Ruff does not have to reinvent everything.

I replaced tools like autopep8 with ruff because it's faster. I haven't even considered benchmarking black because "By using Black, you agree to cede control over minutiae of hand-formatting." translates to "Our creation is not fit for purpose by design."
I'm one of those people who refused to use rustfmt until a mix of new configuration options and RFCing its defaults closer to my preferred style allowed me to stand my ground on the style I like.
Thankfully, the rustfmt devs are sane and my rustfmt config these days is just:
match_block_trailing_comma = true
use_field_init_shorthand = true
use_small_heuristics = "Max"
use_try_shorthand = true

Working on bad-open-mode / W1501.

W1406 can be removed from the list, it's a duplicate of UP025

W0212 is implemented with SLF001

The broad-exception-raised is caught by the TRY002 rule

Thanks @pythonweb2, appreciate these, I'm updating the list...

consider-using-from-import / R0402 is already implemented.

working on nan-comparison.

Noticed that E1300 is implemented but not checked off at https://github.com/astral-sh/ruff/issues/970#issue-1469044346

R0202
R0203
PLR1733
PLR1736

can be checked off, they were merged within the last day.

Noting that E0100 was implemented here (under the name yield-in-init) but is not checked off

For other users' reference, here is a pyproject.toml section that enables only Pylint checkers that aren't as of now covered by Ruff (not using its formatting functionality yet).  Ref:
https://pylint.readthedocs.io/en/stable/user_guide/messages/warning/unused-variable.html
https://pylint.readthedocs.io/en/stable/user_guide/messages/warning/possibly-unused-variable.html

I stand corrected! Thanks @tusharsadhwani

simplifiable-if-expression is already implemented with SIM210 and SIM211 and some rules like E713.
simplifiable-if-statement is already implemented with SIM108.
simplifiable-condition and simplify-boolean-expression could extend the behavior of SIM222 and SIM223.

About pylint unused-private-member / W0238, I suggest that it should actually deal about private members, and not about members with mangled names

I'd be very interested inundefined-loop-variable /  W0631 as it has caused a bug in some of my team's software. We are currently running pylint and only enabling that rule.

W0604 can be crossed off, implemented https://github.com/astral-sh/ruff/pull/8058

Is method-cache-max-size-none almost B019?   Should B019 be adjusted to match?

keyword-arg-before-vararg / W1113 is marked completed by B026, but I don't think these are the same.  B026 checks calls whereas W1113 checks definitions.
I think we need a rule that catches:
def f(x=1, *ar, **kw):
    pass

Is there anyone who work no-member / E1101 in progress or any plans? Can I try to contribute no-member / E1101 rule?

Is there anyone who work no-member / E1101 in progress or any plans? Can I try to contribute no-member / E1101 rule?

Not a maintainer, but that rule might be difficult to implement at present as Ruff lacks cross-file analysis (and non-trivial type deduction).

@tjkuson Thanks for you comments. I wasn't aware of it. Let me await for it

Is it possible to add E0601/used-before-assignment?

@heso Do you wish to add it to the list? If so, it's already there. Or, do you want to work on it?

If so, it's already there

when i try to check simple example:
def foo():
    p = 0
    if p > 1:
        t = 1
    t += 1

ruff (0.1.14) doesnt match incorrect behavior for t.

Sorry if I wasn't clear but I meant the list in the issue description. The rule hasn't been implemented yet which is why you don't see it being flagged in your example.

The C406 rule for dict literals does not cover the init_with_keyword case

I came here looking for something to start on.  Perhaps the description of the issue could have some explanation? Even a link to the contributing docs that detail how to add a new rule would be good.  And the checklist at the top here could use an explanation: what does it mean to be checked off vs crossed out?

That's a nice idea -- I'll add some info. (To answer that specific question: checked off implies that the rule has been implemented, while crossed out implies that it won't be implemented (typically because it's Pylint-specific in some way).)

@charliermarsh what was the reasoning behind crossing out duplicate-argument-name? that one doesn't make sense for me.

checked off implies that the rule has been implemented, while crossed out implies that it won't be implemented (typically because it's Pylint-specific in some way)

That's what I would have guessed, but it'll be good to spell it out, esp on a "good first issue".  Also, the two different message identifiers for some rules could be explained.

@tusharsadhwani - IIRC, because it's already a syntax error.

PLR1703 is already implemented as https://github.com/MartinThoma/flake8-simplify#SIM210

PLR1703 is already implemented as MartinThoma/flake8-simplify#SIM210

@Skylion007 Not quite, SIM210 only runs on if-expressions (ternary), PLR1703 is for if-statements.
SIM108 is the closest thing we have to PLR1703 at the moment, which turns the if-statement into a ternary. which would then be handled by SIM210 I suppose
However, I do believe SIM210 covers PLR1719 which has not yet been implemented.

Hey I would love to work on bad-super-call don't know in which time frame though but I think is is a doable issue for me.

Hi all, I had a go at R1730/R1731 since I realized this was covered by pylint but not ruff while running them against our code base. Any feedback appreciated on the PR!

Working on chained-comparison / R1716

I can't find an implementation of broad-exception-caught / W0718 -- am I misunderstanding things or is the checkmark on that a mistake?

@jku broad-exception-caught / W0718 might be a subset to blind-except (BLE001). In which case, maybe we can add this code to the list?

Working on chained-comparison / R1716

Holding off on this until #10028 is merged as it would be import to avoid conflicts between the rules. (Plus the way I wrote the initial implementation doesn't work well when implementing an autofix, so need to rewrite a lot of it when I have some more time.)

Implemented (PL)R5601 (confusing-consecutive-elif). Any feedback on the PR appreciated.

working on modified-iterating-dict / E4702

If I am not mistaken, (PL)E1507 (invalid-envvar-value) is missing a checkmark because it was implemented here: https://github.com/astral-sh/ruff/pull/3467

What about configurations currently available in pylint.conf such as

docstring-min-length (see #5860)
max-args

supporting these kind of configurations will make a transition from pylint to ruff more smooth.

tried bad super call was a little bit over my skill gonna work on bad-file-encoding this should be easy for the start sorry, have a nice one you all <3

tried bad super call was a little bit over my skill gonna work on bad-file-encoding this should be easy for the start sorry, have a nice one you all <3

I might give it a go, you got a branch of it open?

jep @chanman3388 but there is barley something working (I am also not sure if this was even the right approach) it is open give it a try https://github.com/nkxxll/ruff/tree/bad-super-call

jep @chanman3388 but there is barley something working (I am also not sure if this was even the right approach). But it could save you some boiler plate code. Branch is open give it a try https://github.com/nkxxll/ruff/tree/bad-super-call

Cheers man, I'll give it a go later, I haven't touched this in a while so I'll be a bit...rusty.
I'll see myself out.

^ @nkxxll

@nkxxll Not sure this helps or anything, but I guess looking at your code mostly you weren't sure what type to check for? Also as it stood, I think your approach would've only caught the one bad-super-call per method, though I think it could've easily been modified to check for more. Is the approach I took clear or sensible? If you'd like some help I'd be happy to give it.

@nkxxll Not sure this helps or anything, but I guess looking at your code mostly you weren't sure what type to check for? Also as it stood, I think your approach would've only caught the one bad-super-call per method, though I think it could've easily been modified to check for more. Is the approach I took clear or sensible? If you'd like some help I'd be happy to give it.

Yes, you are totally right I had no idea which type I had to search...
I'm gonna look at you PR again. I'll get back to you if I have any questions, thanks 😇😊.

Going to give a go at class-variable-slots-conflict (E0242)

PLR1706 was removed, I think you can remove it from the list

@canassa removed from pylint? That's great, I was so annoyed about that tuple today!

@kaddkaka No, removed from Ruff 😆

@chanman3388 if you want to have a little issue to wrap up you can finish the bad file encoding lint. I also have a branch for that would love to see how you solve it (though I hope my problem is only in the testing infrastructure). I personally have the feeling there is a hard skill issue on my side with Rust and Rust infra structure.
see the branch https://github.com/nkxxll/ruff/tree/bad-file-encoding

@chanman3388 if you want to have a little issue to wrap up you can finish the bad file encoding lint. I also have a branch for that would love to see how you solve it (though I hope my problem is only in the testing infrastructure). I personally have the feeling there is a hard skill issue on my side with Rust and Rust infra structure.
see the branch https://github.com/nkxxll/ruff/tree/bad-file-encoding

Sure I'll take a look. What in particular to you feel you have an issue with? If you're on the ruff discord I'd be happy to discuss further.

Sure I'll take a look. What in particular to you feel you have an issue with? If you're on the ruff discord I'd be happy to discuss further.

Yes I am let's chat there...

E0401 will really help from refactoring perspective. As soon as you move something in different file/dir it will start complaining. This will eliminate the runtime exceptions of wrong imports if by accident you forgot to fix them everywhere.

I will work on modified-iterating-set / E4703.

Can the compatibility table include the source of the pylint check and whether it is optional? I am not sure of the best way to add that to the table, perhaps just at the end of the line.
When aligning ruff with an existing pylint rule set, or pylint defaults, this info would help to determine whether the corresponding ruff rule should be enabled.
For example, ruff supports magic-value-comparison, R2004 (PLR2004), which is great, but a relatively noisy check. However, R2004’s rule documentation indicates that it is enabled by the optional ‘magic-value’ checker, so you might not wish to enable this ruff check if you wish to align with pylint defaults.
There is more needed to ease migration, for example calling out configuration differences for the checks, but just highlighting optional ones would be a great start. I suppose the best level of compatibility would be to read pylintrc and write a ruff.toml, which would be significant effort, but might ease version upgrades as you implement new rules.
Of course, I am not trying to request major work here, just trying to identify the best strategy. I mapped out the rule origins once about a year ago and might be able to add.

@pjspereira - For what it's worth, we've stopped adding Pylint rules that come from Pylint extensions. In hindsight, we may not have added that rule if it were proposed today.

E0102 is covered by F811

C0303 is covered by W291

R1719 is covered by SIM210 and SIM211

function-redefined rule in pylint E0102 and pyflakes rule F811 is not the same, see https://github.com/astral-sh/ruff/issues/10522 for details.

E0601 is covered by F821

broad-exception-caught / W0718 is checked, but it's missing that it is covered by BLE001

Hi all, I had a crack at W0601. Any feedback appreciated on the PR!

E0102 is covered by F811

It's not. I already said this in my previous comment, but wanted to make sure you and @charliermarsh see this.
Should we consider a rule as implemented for cases that are not explicitly meant to be reimplementations (as pep8 > pylint as I'm guessing)?

consider-using-augmented-assign / R6104 can be marked as done (#9932)

FYI pylint 3.1.0 added more checks, there's at least: R1737: Use 'yield from' directly instead of yielding each element one by one (use-yield-from)

@xrmx Pylint's R1737 is covered by PyUpgrade's UP028

I had a go at the invalid dunder rules (PLE0303, PLE0305, PLE0308, PLE0309). Any feedback is appreciated on the PRs.
Note: I could not figure out why the cache::tests::same_results::ruff_linter_fixtures test (and others) break. All is fine locally until commit 670d66f, but then with the next commit, c221035 (which added a new rule), these tests start to fail. Any ideas please?

R1732 is covered by SIM115

It would be awesome if ruff could support setting --allow-global-unused-variables=no 🎉  https://pylint.readthedocs.io/en/stable/user_guide/configuration/all-options.html#allow-global-unused-variables

It would be awesome if ruff could support setting --allow-global-unused-variables=no 🎉 https://pylint.readthedocs.io/en/stable/user_guide/configuration/all-options.html#allow-global-unused-variables

I would like to work on this, if nobody is on it. We would like to use ruff at my workplace but we also require this rule.

What rule does that setting impact?

This is essentially Unused Variable (F841) except at Module scope instead of Function scope the way we understand it. My idea was to basically handle it in deferred_scopes when doing other ScopeKind::Module rules.
Since F841 is handled specifically for function scopes, I think it would probably be necessary to create a new rule (PyLint's W0612 perhaps) for this particular version of unused variable.

new rule in pylint 3.2.0: contextmanager-generator-missing-cleanup

Just raising it here from #11600

no-method-argument / E0211 (N805)

Is (possibly) incorrectly marked as done ⬆. But is not implemented as part of N805.

Thanks, updated!

I had the intuition that if I could disable all the rules stated here in my .pylintrc and that it should speed up pylint significantly, making it more bearable to live with - especially as a commit hook - and increasingly as more rules get tackled here. Well I wanted to share some results here in case someone is thinking the same. This is in Apache Superset that has a fair amount of python code.
Before disabling all the rules above:
real    0m46.724s
user    1m24.896s
sys     0m6.318s

After:
real    0m42.501s
user    1m17.920s
sys     0m9.299s

So pylint works in mysterious ways, and disabling half+ the rules doesn't seem to help it much unfortunately ... No action needed here, just thought it'd be relevant to people visiting this issue.

I'm not too surprised with your data @mistercrunch, the main cost in pylint is ast parsing and inference and if there's a single check that require inference we pay the full cost upfront. The checks that use inferences are the costly one and are harder to implement in ruff (so by disabling the rules ruff has, you're probably deactivating the fastest pylint checks). And it would make sense for the fundamentally slow checks in pylint like duplicate-code to be the one that will never ends up in ruff.

C0206 was done #11688

Working on chained-comparison / R1716

Holding off on this until #10028 is merged as it would be import to avoid conflicts between the rules. (Plus the way I wrote the initial implementation doesn't work well when implementing an autofix, so need to rewrite a lot of it when I have some more time.)

I am interested in working on R1716, but it looks like it is blocked by #10028, which is blocked by #1774.
Is it worth unblocking this by starting with a smaller rule which does not conflict with #10028? Specifically, only consider monotonic chained comparisons (a < b < c) and ignore non-monotonic chained comparisons (a < b > c), since I assume that this is what people actually care about when they think about chained comparisons?
I'm not sure on people's feelings for rules that diverge in behavior from the original pylint rule over edge cases.
@tjkuson I am interested in your input since you worked on this before

@charliermarsh As discussed in #11808, R0901 shouldn't be worked on until multifile analysis is possible.

@alexcdennis You might want to take a look at #11807, which tries to implement R1716.

i think unidiomatic-typecheck should be unchecked, since E721 no longer bans comparisons using the is operator as of #11220, but unidiomatic-typecheck does

I wrote bash script to exclude ready roles from tool.pylint pyproject section
curl https://api.github.com/repos/astral-sh/ruff/issues/970 | jq -r .body | grep -F [x] | cut -d'/' -f 2 | cut -c 3-7 | awk '{printf "\"%s\",", $1}'

I wrote bash script to exclude ready rules via [tool.pylint].disable pyproject.toml section
curl https://api.github.com/repos/astral-sh/ruff/issues/970 | jq -r .body | grep -F [x] | cut -d'/' -f 2 | cut -c 3-7 | awk '{printf "\"%s\",", $1}'

shebang it for clarity. dont work with zsh

or just replace [x] with '[x]' making it compatible with zsh.

Several rules in the list, like W1202, map to just G  in the parenthetical - I'm fuzzy on which rule is that exactly?

Just a heads up, three renamed Pylint convention messages at the Convention level (renamed for 3.0 earlier this year) are appearing by their old names in this list:
Unchecked:

compare-to-zero / C2001 is now use-implicit-booleaness-not-comparison-to-zero / C1805

Checked:

compare-to-empty-string / C1901 is now use-implicit-booleaness-not-comparison-to-string / C1804
unneeded-not / C0113 is now  unnecessary-negation / C0117

consider-using-from-import / R0402 can be checked off, exists already as manual_from_import

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

@charliermarsh any advancements in that direction ?
(just got bitten by not having one of those)

lucaspar wrote:
I ported the script of @cidrblock to run interactively without setting up a local env.

There was an error from a ~strikethrough~ rule in the original post — here's a patched version (uses bs4's find_all) — https://trinket.io/python3/2341d58536
As of that script's output, Ruff has implemented this much of the Pylint rules:

✅ 215 / 380 (56.58%) implemented


Fixing CommandBarFlyout lifetime crashing bug

Description
The onCompleteFunc function provided to CommandBarFlyoutCommandBar::PlayCloseAnimation method would sometimes be executed on an already destroyed CommandBarFlyout, causing an app crash.
Motivation and Context
This problem recently surfaced when a consumer called CommandBarFlyout.Hide in a FlyoutClosed handler. By the time the closing animation completed, the CommandBarFlyout may already have been destroyed. The app would crash in the onCompleteFunc function execution, while operating on a destroyed instance.
The fix is to pass a weak reference to the CommandBarFlyout instance alongside the onCompleteFunc function and check if that object is still alive before invoking onCompleteFunc. The call is skipped otherwise.
How Has This Been Tested?
Manually tested the application that surfaced this bug and could no longer repro. It was originally repro'able within a couple minutes while OS & Style animations are turned on.
Expanded the MuxControlsTestApp to optionally cover CommandBarFlyout.Hide being called in FlyoutClosed handler.
Created a new regression test with that scenario, which required the use of DefaultCommandBarFlyoutCommandBarStyle with its animations turned on.

/azp run


Kong API Loopback method can not protect the admin API

Summary
I refer to this document and use Kong API Loopback to protect admin API.I added <IP_ADDRESS>:8001 to the service and added the Basic Authentication plug-in to it.the result was that I was not required to authenticate when I visited <IP_ADDRESS>:8001, but was required to authenticate when I visited <IP_ADDRESS>:8000.
Steps To Reproduce
1.add service,parameter is {'name':'kong_admin','host':'<IP_ADDRESS>','port':'8001'}
2.add routing for service,parameter is  'paths':'/'
4.add plugin for service or route,parameter is  {'name':'basic-auth','config.hide_credentials':'true'}
3.add consumer,parameter is   {'username':admin}
4.add certificates,parameter is  {'username':username, 'password':password}
finally
5.access to <IP_ADDRESS>: 8001 is not restricted.
6.access to  <IP_ADDRESS>:  8000 is required for username and password**
Additional Details
my kong.conf :admin_listen = <IP_ADDRESS>:8001, <IP_ADDRESS>:8444 ssl
kong version is 0.14.1

the result was that I was not required to authenticate when I visited <IP_ADDRESS>:8001, but was required to authenticate when I visited <IP_ADDRESS>:8000.

That is the expected behaviour.
These sort of questions are best answered over at Kong Nation check it out if you haven't already :)

the result was that I was not required to authenticate when I visited <IP_ADDRESS>:8001, but was required to authenticate when I visited <IP_ADDRESS>:8000.

That is the expected behaviour.
These sort of questions are best answered over at Kong Nation check it out if you haven't already :)

Hello, if this is the expected behavior, how can we protect the 8001 port?
After all, all rest requests are done through 8001 ports.

I think my 8001 port needs authentication, and the 8000 port does not need authentication. How do I do it?

If you use the loopback method, then should only make requests via the proxy port (i.e. 8000 in your case). The admin api port should be locked off to anything aside from localhost (which it is by listening only on <IP_ADDRESS>).

I think my 8001 port needs authentication, and the 8000 port does not need authentication. How do I do it?

If you use the loopback method, then should only make requests via the proxy port (i.e. 8000 in your case). The admin api port should be locked off to anything aside from localhost (which it is by listening only on <IP_ADDRESS>).

God, I see. It's wonderful. thx ！


v4 Docs: ion-virtual-scroll

Rendering the sample incorrectly.
Also, mark internal attributes as hidden or provide information about them. see domRender as an example.

Odd way to report a bug.

[image: Screen Shot 2018-08-05 at 9.31.00 PM.png]
Here is the rendering issue.
On Sun, Aug 5, 2018 at 8:54 PM kael<EMAIL_ADDRESS>wrote:

Odd way to report a bug.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ionic-team/ionic/issues/15032#issuecomment-410581784,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAgOA3eYHt-CkJeFcwSdd4flI8MNdjtaks5uN738gaJpZM4Vu2Fb
.

I can't see no image.
What I meant is that you can't open as many tickets describing alleged issues, even more when described in a laconic manner, without even giving some context as suggested by the template you're ignoring.
I'm just a Stencil & Ionic user, but I feel like you should revisit the way you report bugs.
The Ionic team is drawn under more than a thousand of tickets, I'm not sure you're taking the best approach.
For a free software, I would not be able to claim, to demand anything to the Ionic team in such a manner.

Thank you for the concerns, but I am not demanding anything from the team. I am simply contributing to the project but denoting problems. I have been a contributor to the project for some time, and in fact, written several books on it. I will let the team triage and sort the issues. I actually have spoken with team members about reporting issues like this, and they informed me to proceed in this manner.
I ignored the template as it really is for code specific issues. Since these are all documentation issue, which cli I have installed was of no matter to the report
I would have happily tried to fix them (for the solutions I know), but the docs are more complex than they appear. More portions of the docs are auto-generated from the component's themselves, so it is not as simple as editing some HTML and calling it a day.
As to the image, reattaching so you can get a sense of why I am reporting this error.


chore(ci): bump chart-releaser action to v1.5

what

Chart-releaser seems to be failing to update the index.yaml in the gh-pages branch.

why
Hoping a combination of bumping the action and also manually bringing the index.yaml update up to date will help.
tests

references
https://github.com/runatlantis/helm-charts/pull/253
https://github.com/runatlantis/helm-charts/actions/runs/3969254151/attempts/1

From the discussion in #253 , I'm not entirely sure that this will fix the issue.
While reading the error:

hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

I don't know your default GITHUB TOKEN permissions, but you might need to add the write permissions as seen here in their documentation:

Maybe this could be the problem?

aha! that looks pretty promising imo @dgteixeira. Nice catch.
The example for the chart-releaser-action calls this out, as well: https://github.com/helm/chart-releaser-action#example-workflow

yeah @perryao, that was where I got the info, forgot to detail my sources sorry 😅
I'm just trying to help out, because we are avid Atlantis users and we want to try out the most recent features of allowing specific commands only to defined GitHub teams (which is a very nice feature for us) :)
Any help you need just let me know!

yeah @perryao, that was where I got the info, forgot to detail my sources sorry 😅 I'm just trying to help out, because we are avid Atlantis users and we want to try out the most recent features of allowing specific commands only to defined GitHub teams (which is a very nice feature for us) :)
Any help you need just let me know!

oh no worries @dgteixeira. I realized after I commented that your screenshot was already showing what I linked to. That's what I get for skimming :)

@perryao @dgteixeira Appreciate both of your support and contributions. The GITHUB_TOKEN is configured correctly. (see: https://github.com/runatlantis/helm-charts/actions/runs/3969254151/jobs/6804102492#step:1:19)


No check on internet connectivity while loading the messages on cold start.

On opening the application if there is no internet connectivity and someone is already logged in then the message loading will continue for indefinite period. Neither the messages will be loaded nor the toast will be displayed regarding no internet connection.

@kunall17 @timabbott @Sam1301 Please review!

Thanks @harshitagupta30 for reporting. After this merge https://github.com/zulip/zulip-android/pull/316#issuecomment-275897250 messages will be shown in offline mode.

@vishwesh3 Thanks for letting know! I am closing this issue! :+1:


Add option to silence [vidstack] dev mode!

Current Behavior:
[vidstack] dev mode! warning is raised on every rebuild while development.

Expected Behavior:
Add option to silence the warning. Whole development team is getting the message.
Attachments

Sounds like you have a strange dev mode if it rebuilds constantly, and not sure what you mean by whole dev team is getting the message. It's normal for libs to log dev mode as it's not safe for prod. There's no real issue here, you can try filtering console logs if it bothers you that much.


Unable to run qsiprep in using docker or docker-wrapper

After running qsiprep using the command:
sudo python /home/quintin_frerichs/.local/lib/python3.6/site-packages/qsiprep_docker.py /home/quintin_frerichs/data/ds001590-download  /home/quintin_frerichs/data/qsiprep-output participant --participant_label sub-01 --output-resolution 1.3 --fs-license-file=/home/quintin_frerichs/license.txt
I get the following error:
raceback (most recent call last):
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.7/multiprocessing/process.py", line 99, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.7/site-packages/qsiprep/cli/run.py", line 739, in build_qsiprep_workflow
work_dir = opts.work_dir.resolve()
AttributeError: 'NoneType' object has no attribute 'resolve'
qsiprep: Please report errors to https://github.com/pennbbl/qsiprep/issues

Could you try adding a -w argument with the working directory? This is a super unhelpful error message on my part, sorry about that

@mattcieslak thank you!! Was stuck on that for so long.


it dosen'y work

Description
whenever i try to open a show or a movie it says no extractore found an it just stay black
Provider
All
Reproduction steps
i open app
i choose an provider
i open a show
it says no extractor found
Operating system
All
Logs
No response
Please confirm the following

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] If related to a provider, I have checked the site and it works, but not the app.

Same issue Here on Android TV


Rename Layout to ViewController?

One of the objections people have raised to typical dry-view usage is that they don't like the "View objects" (i.e. subclasses of Dry::View::Layout) injecting dependencies and getting objects from repos, etc.
My feeling is that this discomfort people have is because of our name, because we're calling these "view objects". I wonder if it would be better to call them "View Controllers" instead. This feels like a better name for what they actually do: receive input (often straight from the HTTP request), collaborate with other objects, prepare the scope for the template, and then render the template with that scope. In this case, the template is the view and the ruby code is actually a view controller.
WDYT?

Resolved in #16


Primary key with default value

Describe the bug
If the primary key defined with a DEFAULT value - the parser won't treat it as a primary key in the result
CREATE TABLE foo
(
    entity_id        UUID PRIMARY KEY DEFAULT getId()
);

getId() is a function that generate UUID
Postgresql dialect

In result: 'primary_key': []

@walkman90, hello! I released fixes in 0.15.0 version https://pypi.org/project/simple-ddl-parser/, test case with your sample and output: https://github.com/xnuinside/simple-ddl-parser/blob/main/tests/test_simple_ddl_parser.py#L1084


Resolve App crashed on launching in OS v8.0.0.

Description
LEARNER-6595

Create new style named NoDisplayTheme parent android:style/Theme.NoDisplay, that overrides the windowIsTranslucent attribute/property.
Tested on Android Kitkat, Lollipop, and Oreo.

PR looks good to me. Just a nit mentioned.


Fix width of magic-digit 2 in the documentation

Hi!
I've been using the magic digits in my project, and it works great, except that magic digit "2" does not seem correct.
I think it's 988 pixels wide instead of 987.

Thank you for reporting this. 👍
I'm not going to merge this for one simple reason: It's actually supposed to be 987 wide because the numbers come from the Fibonacci sequence. I made a mistake and forgot to adjust that one for the 1 wide hard coded spacing that gets added on. 😳
I've fixed the error in the font and released v4.1. Again, thank you for bringing this to my attention.

Every other Fibonacci number! I can't believe I didn't spot that 😅


Use CKAN_INI in celeryd2 run all

paster --plugin=ckanext-archiver celeryd2 run all script could pull CKAN_INI environment variable instead of specifying it by hand

Sounds good to me


package leech for distribution (e.g. PyPI)

The goal here is to make user installation of leech easier.
This is my first time doing packaging in Python 3, so I'm not exactly sure what best practices are these days, but I gave it a shot.
This uses Flit for building the distribution. It seems to be working well with little fuss.
I've confirmed that I can point pipx at this branch and it'll grab it, put it in its own venv with its dependencies, and link the executable leech script in to ~/.local/bin/, which is pretty slick.
And in theory, you can use flit to upload the package to PyPI, though you'll have to pick a different dist-name because some other "leech" is already on PyPI.
The biggest unresolved thing about this in my mind is what to do with requirements.txt. I had to put the requirements in the pyproject.toml, as they weren't getting installed by pipx if I didn't. But should they be duplicated from requirements.txt? or should requirements.txt contain only . or -e .? or is requirements.txt not used at all in this tool chain?
To install requirements in your own development environment, I've found that running flit install in your local checkout will do it. (it recommends the --symlink flag for development use).

[ ] probably also should update the Travis config in some way? Especially if requirements.txt isn't relevant. Maybe have it run flit build instead?

Okay, I have forged ahead with some presumptuous changes, like deleting requirements.txt entirely!
It's okay, we have version control, we can get it back if that was a Poor Decision.
I also pared down the requirements (in pyproject.toml) to only leech's direct requirements, not the entire tree. It's still murky because pip & PyPI is primarily a tool for distributing libraries for developers to incorporate in their environments, not end-user applications, but this is my best guess.

Now that the project is using poetry, I'm closing this branch that uses flit.

Now that the project is using poetry, I'm closing this branch that uses flit.


URL fix - update to readme file

Change url for read more of query cache title from batch update article to query cache article url.

Hello @mahab339 ,
Thank for fixing our mistake ;)
Best Regards,
Jon


Generate: add RandomNormalNumber() to return a double

This works now:
double x = ScottPlot.Generate.RandomNumber();

and it would be nice if this worked:
double x = ScottPlot.Generate.RandomNormalNumber();

(with similar overloads)
Note that there is already ScottPlot.Generate.RandomNormal() which returns double[]

The new function can be placed below this one
https://github.com/ScottPlot/ScottPlot/blob/fb3b1c84af3c361bf1eb8f4286ad1d4e7038afc5/src/ScottPlot5/ScottPlot5/Generate.cs#L355-L358

Even easier, it looks like Generate.RandomData.RandomNormalNumber() already exists, so the proposed function can just forward its value


EM-3236 DG API : Investigate DG api failing nightly build jobs

Before creating a pull request make sure that:

[ ] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[ ] tests have been updated / new tests has been added (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
Change description
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[ ] No

Not required


support releasing at a specific commit

Is your feature request related to a problem? Please describe.
Sometimes a maintainer does not want to release all of the changes on HEAD. For examples a person might land an import bug fix and then a small feature request after. It would be nice if release-please could target a commit release all changes up to that point. So in this example target the bug fix and not include the feature.
Describe the solution you'd like
Honor a comment command on the PR to set the commit where release-please should stop processing. Example /targetCommit someHash.
Describe alternatives you've considered
Support only from the CLI mode.

I think you can do this already assuming you are doing this as a one-off and not automated process.
Consider the following git history:
[aaaaaa] chore: release 1.2.3
[bbbbbb] fix: some bugfix
[cccccc] feat: some feature

You can create a new "release branch" and target it for the release.
# create a new branch from the target bugfix
git checkout bbbbbb
git checkout -b 1.2.3-bugfix
git push -u origin 1.2.3-bugfix

# run release-please against the new bugfix branch
release-please release-pr \
  [other args]
  --default-branch=1.2.3-bugfix

This will open a release PR against your 1.2.3-bugfix branch and only see the commit history on that branch. In this case, it will see commit bbbbbb as the only releasable commit since the last release aaaaaa.

Thanks @chingor13 this is good enough for my use case. It might be nice to have use-cases like this documented in a wiki or readme. Closing as it seems like the behavior is supported well enough.


🚀 Feature: Use user gitlab token for register existing component (catalog import)

🔖 Feature description
You should add possibility of use user token for get yaml file into repository for registing existing component.
🎤 Context

Avoid a static gitlab token
Use user repository permission for allow/deny add a component

✌ Possible Implementation

app-config.production.yaml

catalog:
  rules:
    - allow: ["Component", "User", "Group"]
      useUserToken: true # true = user token, false = global token
      locations:
        - type: url
          pattern: https://gitlab.example.com/**

👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, but I'm happy to collaborate on a PR with someone else

This could be nice, but it is hard to implement currently. The tricky part is that the user tokens will expire, so we really need to be storing and using the user refresh tokens for offline access, which we currently don't have any infra for.
I'm also a bit torn on whether it actually makes sense in practice. It seems like it would introduce issues for example with certain users being responsible for a lot of components, potentially leading to rate limiting issues because user tokens generally have lower rate limits than other types of integrations. It'd also be a problem to off-board users, where ingestion might suddenly start failing.

Some more info discussed as part of #24815: GitLab invalidates existing access and refresh tokens when any form of new session is created. That effectively means that this isn't possible to implement for GitLab in a clean way without requiring additional auth integrations.

Okay ! Thank you for your comeback.

Closing as responded to!


Require g:rspec_runner explicitly

If g:rspec_runner is not provided
the g:rspec_command will be piped to GUI vim as-is.
This allows users to use vim-dispatch with GUI vim.

ping @christoomey @jferris

The only problem I see here is that out-of-the box, this doesn't work for MacVim because the default spec command won't work without !. Could we maybe provide a default runner only when a custom command and a custom runner aren't provided? Any other ideas?

Overall I think the explicitness requirement is fine, and the readme updates seems good to cover the change. I did have one concern about recommending they add their custom script to the plugin bin/ directory which I commented on inline.

Thanks, @christoomey.


[explorer] coins and objects rewrite

Description

Test Plan
Running against testnet addresses a and b
Type of Change (Check all that apply)

[x] user-visible impact
[ ] breaking change for a client SDKs
[ ] breaking change for FNs (FN binary must upgrade)
[ ] breaking change for validators or node operators (must upgrade binaries)
[ ] breaking change for on-chain data layout
[ ] necessitate either a data wipe or data migration

Release notes
Updated Owner Objects View
Introduced reusable Pagination Component

@Nikhil-Mysten the title "Owner Objects" should be "Owned Objects"


New Access List dialog buggy behaviour

With the new release (2.9.0) and the ability to add more than a few IPs, I am trying to create a new list and experiencing some bugs. There seems to be a label missing for a button (see screenshot). Also when I enter an IP address and click the Add button, all previously entered IP addresses disappear.
To Reproduce

Once logged in, click Access Lists
Click Add Access List
Click Access tab
Enter an IP address
Click the Add button

Expected behavior
The button should have a label and when I click Add, all previous IP addresses should not disappear

May I ask where you see the new access list? I got 2.9.2 installed and I still can only add 4 possible IP addresses / ranges.

Once you log in, click "Access Lists" on the top menu and then the "Add Access List" button on the top right. You can add multiple entries by clicking the "Add" button. See screen captures attached.

Thanks, was a caching issue in my browser. I can confirm the behavior on a newly created list (clicking add deletes all previous entries).
It works though, once the list is created (e.g. with one or two items), saved and opened again. Afterwards if you click add, existing entries are still available.

Also I have noticed that on every change in the Access List, I had to open the Proxy Host settings again (no need to change anything) and press Save.


Removed "nodeunit" from regular "dependencies"

nodeunit is only required in "devDependencies" where it's present already.

Hi @powmedia, do you have any objections against merging this?

dead project


API documentation and Agreements

To improve interop with our APIs we could:

Use schema.org-actions as agreement subjects and offer entry-point declarations for APIs. “Buy-Action ⇔ Offer”

https://schema.org/Action
https://schema.org/docs/actions.html potential actions
https://schema.org/EntryPoint
https://www.w3.org/wiki/images/1/10/PotentialActionsApril11.pdf
https://actions.semantify.it/ respectively https://actions.semantify.it/api-docs/

RestDesc description of APIs http://restdesc.org/
Hydra description of APIs https://www.markus-lanthaler.com/hydra/
Sitemaps (sitemap.xml)
VoID descriptions
TPF endpoints https://www.ibm.com/support/knowledgecenter/en/SSB23S_<IP_ADDRESS>/gtpd4/dd_endptgrp.html

@fkleedorfer close/later/soon/ready?

is in our internal kanban board now


fix(core): trigger new release

I forget to release the changes in https://github.com/ocavue/prosekit/pull/539

/publish


layer fences

Fences that are strictly stronger than each other should contain both the strong and weak annotation. This makes reducing the tests straightforward.

I'm setting things up so that:

in ARM, dmb implies dmb.st, and dmb implies dmb.ld (and isbs are incomparable),
in Power, sync implies lwsync, and sync implies eieio, (and isyncs are incomparable), and
in PTX, membar.sys implies membar.gl, and membar.gl implies membar.cta.

Does that sound about right?

The PTX ones look good!
By transitivity membar.sys implies membar.cta right?

Right!