On 12 mars 16:47, Sarah Strong wrote:
> Hey, all,
Hi Sarah,
> 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.
[snip]
> 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.
I'm +1 on this, please put the priority on that one
> 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.
hum, I'm more dubious about that one. I think we should start with small
improvments like adding whick 'kind' of regexp matched (constant, class, etc...)
and may be an example. But the example wouldn't be that simple since user
may customize the regexp, so I wouldn't spent that much time on this.
> 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.
why not. We should discuss more about this.
In a similar fashion, do you know the --help-msg option ?
> * 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.
>
> 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
I agree with Marteen on this. One thing we could easily do would be to display
the formula.
> 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.
#1 !
--
Sylvain Thénault LOGILAB, Paris (France)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
CubicWeb, the semantic web framework: http://www.cubicweb.org
_______________________________________________
Python-Projects mailing list
Python-Projects@lists.logilab.org
http://lists.logilab.org/mailman/listinfo/python-projects
