Giovanni Bajo wrote:
Blair Zajac <[EMAIL PROTECTED]> 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
_______________________________________________
Svnmerge mailing list
[email protected]
http://www.orcaware.com/mailman/listinfo/svnmerge
