Hey, all,
We were hoping to make a couple of modifications to pylint's output in order
to help with progress on the "Bad first impression" ticket
*Possible output improvement #1:*
Avoid repeated output of related errors in the same file/method/class.
Current output:
************* Module Kontroller
W: 9: Bad indentation. Found 2 spaces, expected 4
W: 10: Bad indentation. Found 2 spaces, expected 4
W: 11: Bad indentation. Found 2 spaces, expected 4
W: 12: Bad indentation. Found 2 spaces, expected 4
W: 15: Bad indentation. Found 2 spaces, expected 4
W: 19: Bad indentation. Found 2 spaces, expected 4
W: 21: Bad indentation. Found 3 spaces, expected 8
W: 22: Bad indentation. Found 4 spaces, expected 12
Proposed output:
************* Module Kontroller
W: 9: Bad indentation. Found 2 spaces, expected 4
W: 10: Bad indentation. Found 2 spaces, expected 4
W: 11: Bad indentation. Found 2 spaces, expected 4
W: 12: Bad indentation. Found 2 spaces, expected 4
[4 more Bad indentation messages, use --unabridged to display them all]
The idea here being that the general theme of the error is easily inferred
and doesn't need to be repeated. This is particularly important for new
users who may have consistent errors in their source. This often gives
hundreds of a single type of error for a large project - errors that can be
selectively silenced, of course, but automatically abridging output could
help from discouraging first time users.
*
Possible output improvement #2*
Errors such as
C: 11:initPickleData: Comma not followed by a space
pickle.dump(j,f)
^^
are very nice because they are clear about what is wrong with the code.
Errors such as
C:111:Kontroller.addWord: Invalid name "addWord" (should match
[a-z_][a-z0-9_]{2,30}$)
C: 89:Kontroller.checkUserId: Invalid name "checkUserId" (should match
[a-z_][a-z0-9_]{2,30}$)
are a bit confusing because the user may be unsure of why such a pattern
match
is necessary.
A possible idea to make certain errors clearer would keep track of which
errors
produced, and then create a seperate table with documentation links
detailing
the error in greater depth.
Current output for Messages:
--------
+-----------+------------+
|message id |occurrences |
+===========+============+
+-----------+------------+
|E0602 |2 |
+-----------+------------+
|W0612 |1 |
+-----------+------------+
|W0301 |1 |
+-----------+------------+
|F0401 |1 |
+-----------+------------+
Proposed output for messages:
+-----------+------------+-------------+
|message id |occurrences |reference |
+===========+============+=============+
+-----------+------------+-------------+
|E0602 |2 |PEP 333 |
+-----------+------------+-------------+
|W0612 |1 |http:// |
+-----------+------------+-------------+
|W0301 |1 |file:///....-+
+-----------+------------+-------------+
|F0401 |1 |(field empty)|
+-----------+------------+-------------+
where the links might be to the pylint error code wiki, python peps,
pylint documentation, or local documentation.
* Possible output improvement #3*
Modify pylint's rating system not to give negative ratings out of ten. This
doesn't match up to most people's expectations of how a rating works.
Current output:
Your code has been rated at -6479.99/10 (previous run: -6479.99/10)
Proposed output:
Your code has been rated at 0/10 (previous run: 0/10)
or
Your code has been rated at -6479.99 (best possible mark 10) (previous run:
-6479.99)
or
Your code has been rated at 6479.99/10000
Let us know which, if any, of these features you'd like us to pursue and
we'll write up a ticket. Each could possibly be implemented as an option, or
as the default behaviour.
Thanks!
-Sarah and Fletcher
University of Toronto team
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
