Re [Svnmerge] Noisy pychecker on svnmerge.py

[Blair Zajac]

Giovanni Bajo wrote:
> Blair Zajac <blair at orcaware.com> wrote:
> 
> 
>>>-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?
> 
> 
> 
> I'll add also that there are semantic differences between these languages.
> There are many things in C/C++ which trigger undefined behaviour *but* a
> compiler is forced *not* to diagnose them. For instance, even if a compiler
> can prove that you're freeing a NULL pointer, it must not halt compilation.
> The only thing it can do is to issue a warning. The same applies to many
> other cases (delete of a pointer of non-complete type, type aliasing
> violation, array boundary overflow, ecc.) where the application *will*
> (often) crash at runtime, but the compiler can *not* abort compilation. This
> is why -Wall exists.
> 
> Python does not have these problems. There are cases where the application
> will work sometimes and hit a UnboundLocalError due to a typo only on some
> code paths -- those are useful errors diagnosed by PyChecker and patches are
> welcome. But most of those I see when I try to run these tools on my Python
> code is just noise or hints at coding styles I deliberately and postively
> disagree with, and do not want to follow. For instance, PyLint triggers a
> warning (*by default*) if you use a variable name shorter than 3 characters.
> That's so unreasonable I won't ever comment it.
> 
> But don't worry, I'm not going to be anal on that :) If you want to
> rearrange code to shut down some warnings, feel free to do it. I'll just
> object such changes when they make the code harder to read or more
> complicated.

Then I think we agree!

Blair