#29 #$pycheck_no[=re-pattern]


This patch enables to make pychecker quiet on source code line basis by adding a "#$pycheck_no" comment (=quiet on all errors concerning this line) or a "#$pycheck_no=re-pattern" comment (quiets the message if the re-pattern is found inside the message).
Example: "def __init__(self): #$pycheck_no='Base class .* not called'"

A re-pattern can of course use OR (|) syntax to stop more warnings specifically.

The patch also solves problems with pychecker when not called from the current working directory.

Without that #$pycheck_no possibilty I'm not able to achieve a zero-waring status for big existing code.
Also there are often situations where it is not worth the effort or not really possible to tell ignoring patterns specifically and complicatedly through a .pycheckrc. Thus telling a NO! on source line basis upon actual warnings is the best/practical practice in my opinion.
Thus I'd like to see this feature in future regular pychecker distribution.
I'm running this thing since about 6 months successfully with a lot of projects.

I'll also post my pychecker plug-in module for PythonWin which enables to use pychecker easily in PythonWin (usage similar to the exising Grep-Tool (Ctrl-N,P) - but can run in background due to the time consuming pychecker task):
One can jump to Warning source lines by DoubleClick and auto-add #$pycheck_no / #$pycheck_no=specific-re-pattern tags to source lines by simply context/right-mouse-clicking on warning lines.

I'd also like to use the same class names as .pycheckrc for stopping specific errors. Yet I found, that these Warning class ID strings are not stored currently in the Warning objects and are thus not trackable easily so far. Maybe this basic possibility should be added in future to have a Warning class tag avaible for better post-processing of Warnings.



  • kxroberto

    kxroberto - 2006-12-27
  • Neal Norwitz

    Neal Norwitz - 2007-04-23

    Logged In: YES
    Originator: NO

    This is interesting. I need to look at the patch closer and fix some style nits. But the basic idea and implementation should work. My only concern is speed if you have to read all the source files. This might have to be disabled by default.

    Feel free to add more patches! :-)

  • kxroberto

    kxroberto - 2007-04-23

    Logged In: YES
    Originator: YES

    Speed / default-disabling is a absolute non-issue regarding my experience. It uses the linecache. Only files with errors have to be opened (post processing). And reading the source file lines is much much faster than the checker job.

    style nits of course :-)

    Somewhat questionable is the re-matching (only) on human readable warning messages (which are possibly changing during evolution of pychecker). Yet there are no stable/immutable type key-names for the error types in pychecker on output side so far. only on input side in the config files. A future pychecker would possibly put a short immutabel tag-name in front of every warning line. E.g. the same key-names as used for the filter config. Printing those type key-namse would also make adjustment of the config files much easier. pycheck_no=... could then alternativly match on those key-names. The optional matching on human readable messages should possibly be preserved anyway...

  • kxroberto

    kxroberto - 2009-05-10

    reworked patch after minor rejections in 0.8.18

  • kxroberto

    kxroberto - 2009-05-10

    I rebuilt the patch after minor rejections in 0.8.18. No functional change.
    #pycheck_no suppressions worked for me over the years.
    In my experience its almost impossible in larger projects to reach and maintain a clean checker status with suppressions only in .pycheckrc.

  • kxroberto

    kxroberto - 2011-11-25


    Is there meanwhile another solution for suppressing indiviual warnings on the level of lines/comments ?

    Otherwise I would still request this; or similar.


Log in to post a comment.