You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem: Darker only shows linter erros on modified lines. But e.g. when correcting a function signature, mypy easily finds the static typing errors in invocations on unmodified lines elsewhere in the same or other .py files.
Solution: Check out rev1, run the linters, and record their outputs as the baseline. Check out rev2, run them again, and record the result. Similar to Black and Flynt processing, parse git diff output. Hide only linter messages which
fall on an equal chunk, and
also appear in the recorded baseline with an identical messages and a line number corresponding to the chunk's location in rev1.
This still won't solve code moves between files, but it's still vastly better than the current algorithm.
It seems that baseline support in basedmypy is still rather primitive – it uses a heuristic of scanning for the same type checking error within ±50 lines, which can of course lead to false positives/negatives. We should make use of information from git diff gives about moved code, as Darker already does when filtering modifications from Black (and soon Flynt).
I suspect the same applies to flakehell baseline since the baseline file is just a list of hashes, and it doesn't use a diff to track code moves.
Related: We're documenting the current shortcomings in #380.
Problem: Darker only shows linter erros on modified lines. But e.g. when correcting a function signature,
mypy
easily finds the static typing errors in invocations on unmodified lines elsewhere in the same or other.py
files.Solution: Check out
rev1
, run the linters, and record their outputs as the baseline. Check outrev2
, run them again, and record the result. Similar to Black and Flynt processing, parsegit diff
output. Hide only linter messages whichequal
chunk, andrev1
.This still won't solve code moves between files, but it's still vastly better than the current algorithm.
Background:
We found prior art in basedmypy and flakehell baseline.
It seems that baseline support in
basedmypy
is still rather primitive – it uses a heuristic of scanning for the same type checking error within ±50 lines, which can of course lead to false positives/negatives. We should make use of information fromgit diff
gives about moved code, as Darker already does when filtering modifications from Black (and soon Flynt).I suspect the same applies to
flakehell baseline
since the baseline file is just a list of hashes, and it doesn't use a diff to track code moves.Related: We're documenting the current shortcomings in #380.
Originally posted by @akaihola in #328 (reply in thread)
The text was updated successfully, but these errors were encountered: