Re [Svnmerge] Noisy pychecker on svnmerge.py

[Giovanni Bajo]

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