Re [Svnmerge] Noisy pychecker on svnmerge.py

[Giovanni Bajo]

Blair Zajac <blair at orcaware.com> wrote:

>> What are the other issues? I don't like patches to shut up warnings
>> caused by bugs/imperfections in external tools. If the tools help
>> finding out real bugs, that's fine, let's fix them. But I'm -1 on
>> any patch that tries to adjust code so to shut down non-issues
>> and/or change our code to follow some coding convention (like the
>> "is None" issue) the tools unilaterally decided it's the Good
>> One(TM).
>
> The Subversion teams takes care to remove all gcc -Wall warnings from
> the C source code and I don't see why that shouldn't extend to
> svnmerge.py.

-Wall contains a carefully set of warnings, tuned by many developers across the
last 10 years. GCC developers recommend using -Wall -Werror, they know many
people do follow this advice, and try as hard as possible to not break it with
new bogus warnings, avoid false positives, avoid warnings that aren't a clear
indicator of a serious issue in the code, etc. For instance, there are violent
discussions whether a new warning should go to -Wall or -Wextra.

OTOH, pychecker is a recent effort, done by one person, without reaching any
consensus with the Python community. It spews many false positives, contains
even coding style suggestions, etc. Comparing it with -Wall is not correct.
It's more like having "-Wall -Wextra -Weffc++". Moreoever, there are other
competing tools around (see PyLint), which produce other sets of warnings,
other false positives, etc. Are we going to try and get a clear run with PyLint
too?

Giovanni Bajo