Re [Svnmerge] Noisy pychecker on svnmerge.py

[Blair Zajac]

Giovanni Bajo wrote:
> 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?

It would be ideal, but I'm not attached that it has to happen.  I don't think we 
should remove the messages that pertain to supporting older versions of Python, 
but there were suggestions the newer Pychecker found are valid.

Blair