pylint scores

Discussion in 'Python' started by wheres pythonmonks, Jul 30, 2010.

  1. I am starting to use pylint to look at my code and I see that it gives a rating.
    What values do experienced python programmers get on code not
    targeting the benchmark?

    I wrote some code, tried to keep it under 80 characters per line,
    reasonable variable names, and I got:

    0.12 / 10.

    Is this a good score for one not targeting the benchmark? (pylint
    running in default mode)

    Somewhat related: Is the backslash the only way to extend arguments
    to statements over multiple lines? (e.g.)

    >>> def f(x,y,z): return(x+y+z);

    ....
    >>> f(1,2,

    .... 3)
    6
    >>> assert f(1,2,3)>0,

    File "<stdin>", line 1
    assert f(1,2,3)>0,
    ^
    SyntaxError: invalid syntax
    >>>


    In the above, I could split the arguments to f (I guess b/c of the
    parens) but not for assert. I could use a backslash, but I find this
    ugly -- it that my only (best?) option?

    [I really like to assert my code to correctness and I like using the
    second argument to assert, but this resulted in a lot of long lines
    that I was unable to break except with an ugly backslash.]

    W
    wheres pythonmonks, Jul 30, 2010
    #1
    1. Advertising

  2. wheres pythonmonks

    Peter Otten Guest

    wheres pythonmonks wrote:

    > I am starting to use pylint to look at my code and I see that it gives a
    > rating. What values do experienced python programmers get on code not
    > targeting the benchmark?
    >
    > I wrote some code, tried to keep it under 80 characters per line,
    > reasonable variable names, and I got:
    >
    > 0.12 / 10.
    >
    > Is this a good score for one not targeting the benchmark? (pylint
    > running in default mode)


    No. About 5 is typically OK for undocumented code.
    I've heard.

    Ratings do not always make sense:

    $ for f in /usr/lib/python2.6/{glob,csv,doctest,collections}.py; do echo $f;
    pylint 2>/dev/null $f | grep "Your code has"; done
    /usr/lib/python2.6/glob.py
    Your code has been rated at 8.54/10
    /usr/lib/python2.6/csv.py
    Your code has been rated at 6.45/10
    /usr/lib/python2.6/doctest.py
    Your code has been rated at 7.77/10
    /usr/lib/python2.6/collections.py
    Your code has been rated at -4.71/10
    $

    For mainstream code you can easily reach 10 by adding bogus docstrings and
    pointless long variable names, i. e. you can get higher scores for lower
    code quality.

    Peter

    PS: My favourite wtf message is "too few public methods"
    Peter Otten, Jul 30, 2010
    #2
    1. Advertising

  3. wheres pythonmonks

    News123 Guest

    On 07/30/2010 03:12 PM, wheres pythonmonks wrote:
    > I am starting to use pylint to look at my code and I see that it gives a rating.
    > What values do experienced python programmers get on code not
    > targeting the benchmark?
    >
    > I wrote some code, tried to keep it under 80 characters per line,
    > reasonable variable names, and I got:
    >
    > 0.12 / 10.
    >
    > Is this a good score for one not targeting the benchmark? (pylint
    > running in default mode)
    >

    It's not a goodf core, but arrives easily if you never ran pylint before.
    With very little effort you should be able to be above 5
    with a little more effort above 7


    > Somewhat related: Is the backslash the only way to extend arguments
    > to statements over multiple lines? (e.g.)


    if you have an opening parenthesis, or bracked, then you don't need a
    backslash

    so instead of
    if longlonglonglonglonglonglonglongvar == \
    otherlonglonglonglongvar:

    you could also write:

    if (longlonglonglonglonglonglonglongvar ==
    otherlonglonglonglongvar):


    same works of course with asserts.

    >
    >>>> def f(x,y,z): return(x+y+z);

    > ...
    >>>> f(1,2,

    > ... 3)
    > 6
    >>>> assert f(1,2,3)>0,

    > File "<stdin>", line 1
    > assert f(1,2,3)>0,
    > ^
    > SyntaxError: invalid syntax
    >>>>

    >
    > In the above, I could split the arguments to f (I guess b/c of the
    > parens) but not for assert. I could use a backslash, but I find this
    > ugly -- it that my only (best?) option?
    >
    > [I really like to assert my code to correctness and I like using the
    > second argument to assert, but this resulted in a lot of long lines
    > that I was unable to break except with an ugly backslash.]
    >
    > W
    News123, Jul 30, 2010
    #3
  4. wheres pythonmonks

    Matteo Landi Guest

    What are the messages one should really care about while evaluating
    its code using pylint? It's easy to get 5 scored with a "lot of public
    methods" or bad named variables such as 'x' or 'y' .. Have you got any
    config file to share?

    On Sat, Jul 31, 2010 at 2:48 AM, Dan Stromberg <> wrote:
    >
    > On Fri, Jul 30, 2010 at 12:18 PM, News123 <> wrote:
    >>
    >> On 07/30/2010 03:12 PM, wheres pythonmonks wrote:
    >> > I am starting to use pylint to look at my code and I see that it gives a
    >> > rating.
    >> > What values do experienced python programmers get on code not
    >> > targeting the benchmark?
    >> >
    >> > I wrote some code, tried to keep it under 80 characters per line,
    >> > reasonable variable names, and I got:
    >> >
    >> > 0.12 / 10.
    >> >
    >> > Is this a good score for one not targeting the benchmark?  (pylint
    >> > running in default mode)
    >> >

    >> It's not a goodf core, but arrives easily if you never ran pylint before..
    >> With very little effort you should be able to be above 5
    >> with a little more effort above 7
    >>
    >>
    >> > Somewhat related:  Is the backslash the only way to extend arguments
    >> > to statements over multiple lines?  (e.g.)

    >>
    >> if you have an opening parenthesis, or bracked, then you don't need a
    >> backslash
    >>
    >> so instead of
    >> if longlonglonglonglonglonglonglongvar == \
    >>        otherlonglonglonglongvar:
    >>
    >> you could also write:
    >>
    >> if (longlonglonglonglonglonglonglongvar ==
    >>        otherlonglonglonglongvar):
    >>
    >>
    >> same works of course with asserts.
    >>
    >> >
    >> >>>> def f(x,y,z): return(x+y+z);
    >> > ...
    >> >>>> f(1,2,
    >> > ... 3)
    >> > 6
    >> >>>> assert f(1,2,3)>0,
    >> >   File "<stdin>", line 1
    >> >     assert f(1,2,3)>0,
    >> >                      ^
    >> > SyntaxError: invalid syntax
    >> >>>>
    >> >
    >> > In the above, I could split the arguments to f (I guess b/c of the
    >> > parens) but not for assert.  I could use a backslash, but I find this
    >> > ugly -- it that my only (best?) option?
    >> >
    >> > [I really like to assert my code to correctness and I like using the
    >> > second argument to assert, but this resulted in a lot of long lines
    >> > that I was unable to break except with an ugly backslash.]
    >> >
    >> > W

    >>

    > IMO, the important thing about pylint's scoring is that it's but one way of
    > many of producing good Python code.  However, it's also one of the easier
    > ways of producing good python code.
    > I personally like to get my scores up near 10, by annotating in comments
    > about the few things that pylint flags that I can't just code around.  This
    > requires jumping through some slightly silly hoops (EG the previously
    > mentioned "too few public methods", which my various container classes
    > always trip over), but going through this process is worthwhile for
    > highlighting the hoops pylint can detect that -aren't- so silly.
    > The one thing I like to leave unfixed is FIXME's - otherwise my preference
    > would be to go for a score of 10 for production code.
    > I also like to create a ./this-pylint script for my various projects, that
    > have global overrides - things like identifier rules, line length, and...  I
    > don't get blanks instead of tabs.  Blanks are fine if you don't understand
    > tabs (or think someone in the future who doesn't understand tabs will need
    > to work on your code), but tabs allow everyone to see code indented the way
    > -they- want to see it, not just the way the original author wanted to see
    > it.
    > This script (./this-pylint) will also save output from the test in a text
    > file, for make (or other dependency handling program) to use to avoid
    > re-pylint'ing unmodified code.  It'll give an error typically, if pytlint
    > detects any errors other than FIXME's (excluding ones, as I mentioned
    > before, that have a comment disabling the warning, of course).
    > I'm more than a little sad that pylint doesn't seem to be moving to python 3
    > in any big hurry.
    >
    >
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
    >




    --
    Matteo Landi
    http://www.matteolandi.net/
    Matteo Landi, Jul 31, 2010
    #4
  5. wheres pythonmonks

    News123 Guest

    Hi,


    On 07/31/2010 11:04 AM, Matteo Landi wrote:
    > What are the messages one should really care about while evaluating
    > its code using pylint? It's easy to get 5 scored with a "lot of public
    > methods" or bad named variables such as 'x' or 'y' .. Have you got any
    > config file to share?



    The most important ones are of course the errors.
    Some of them might be false, but in our team we agreed, that no file is
    allowed to report pylint errors.
    This means
    - just fixing errors (in most cases)
    - rewriting code (in a few cases)
    - masking errors with pylint directives in the source (some other few
    errrors)




    If you only want to see the errros, then just run
    pylint -E filename.py

    Note: This is a rather new but very useful switch.. It doesn't exist
    on Ubuntu 10.4's release pylint 0.19.0, but exists on pylint 0.21.1



    Apart from that. You should discuss within your team, which
    errors you'd like to have ignored and adapt the pylintrc. This
    is a rather personal decision.
    For one project we disiabled for example following warnings:
    ## C0322 = "Operator not preceded by a space"
    ## C0323 = "Operator not followed by a space"
    ## C0324 = "Comma not followed by a space"
    As we did not have time to rewrite all of the existing code, that
    violated these rules.
    We prefered to 'hide' these warnings in order to sett the more important
    ones.

    On another new project however we did NOT comment therese rules
    and decided, that all new code should follow these rules


    We disabled some special global variables, which we'd like to have in
    lower case

    const-rgx ==((specialvar)|(v_[a-z_][a-z0-9_]*)|([A-Z_][A-Z0-9_]*)|(__.*__))$


    you could also modify variables like
    # Maximum number of attributes for a class (see R0902).
    max-attributes=7

    # Minimum number of public methods for a class (see R0903).
    min-public-methods=2

    # Maximum number of public methods for a class (see R0904).
    max-public-methods=20


    For some graphics module functions for example we wanted to
    be allowed to use variable names like x,y as they are
    completely meaningful names for pixel coordinates.


    so change the entry good-names
    good-names=x,y,ex,Run,_



    Hope, that this gave you some ideas



    >
    > On Sat, Jul 31, 2010 at 2:48 AM, Dan Stromberg <> wrote:
    >>
    >> On Fri, Jul 30, 2010 at 12:18 PM, News123 <> wrote:
    >>>
    >>> On 07/30/2010 03:12 PM, wheres pythonmonks wrote:
    >>>> I am starting to use pylint to look at my code and I see that it gives a
    >>>> rating.
    >>>> What values do experienced python programmers get on code not
    >>>> targeting the benchmark?
    >>>>
    >>>> I wrote some code, tried to keep it under 80 characters per line,
    >>>> reasonable variable names, and I got:
    >>>>
    >>>> 0.12 / 10.
    >>>>
    >>>> Is this a good score for one not targeting the benchmark? (pylint
    >>>> running in default mode)
    >>>>
    >>> It's not a goodf core, but arrives easily if you never ran pylint before.
    >>> With very little effort you should be able to be above 5
    >>> with a little more effort above 7
    >>>
    >>>
    >>>> Somewhat related: Is the backslash the only way to extend arguments
    >>>> to statements over multiple lines? (e.g.)
    >>>
    >>> if you have an opening parenthesis, or bracked, then you don't need a
    >>> backslash
    >>>
    >>> so instead of
    >>> if longlonglonglonglonglonglonglongvar == \
    >>> otherlonglonglonglongvar:
    >>>
    >>> you could also write:
    >>>
    >>> if (longlonglonglonglonglonglonglongvar ==
    >>> otherlonglonglonglongvar):
    >>>
    >>>
    >>> same works of course with asserts.
    >>>
    >>>>
    >>>>>>> def f(x,y,z): return(x+y+z);
    >>>> ...
    >>>>>>> f(1,2,
    >>>> ... 3)
    >>>> 6
    >>>>>>> assert f(1,2,3)>0,
    >>>> File "<stdin>", line 1
    >>>> assert f(1,2,3)>0,
    >>>> ^
    >>>> SyntaxError: invalid syntax
    >>>>>>>
    >>>>
    >>>> In the above, I could split the arguments to f (I guess b/c of the
    >>>> parens) but not for assert. I could use a backslash, but I find this
    >>>> ugly -- it that my only (best?) option?
    >>>>
    >>>> [I really like to assert my code to correctness and I like using the
    >>>> second argument to assert, but this resulted in a lot of long lines
    >>>> that I was unable to break except with an ugly backslash.]
    >>>>
    >>>> W
    >>>

    >> IMO, the important thing about pylint's scoring is that it's but one way of
    >> many of producing good Python code. However, it's also one of the easier
    >> ways of producing good python code.
    >> I personally like to get my scores up near 10, by annotating in comments
    >> about the few things that pylint flags that I can't just code around. This
    >> requires jumping through some slightly silly hoops (EG the previously
    >> mentioned "too few public methods", which my various container classes
    >> always trip over), but going through this process is worthwhile for
    >> highlighting the hoops pylint can detect that -aren't- so silly.
    >> The one thing I like to leave unfixed is FIXME's - otherwise my preference
    >> would be to go for a score of 10 for production code.
    >> I also like to create a ./this-pylint script for my various projects, that
    >> have global overrides - things like identifier rules, line length, and... I
    >> don't get blanks instead of tabs. Blanks are fine if you don't understand
    >> tabs (or think someone in the future who doesn't understand tabs will need
    >> to work on your code), but tabs allow everyone to see code indented the way
    >> -they- want to see it, not just the way the original author wanted to see
    >> it.
    >> This script (./this-pylint) will also save output from the test in a text
    >> file, for make (or other dependency handling program) to use to avoid
    >> re-pylint'ing unmodified code. It'll give an error typically, if pytlint
    >> detects any errors other than FIXME's (excluding ones, as I mentioned
    >> before, that have a comment disabling the warning, of course).
    >> I'm more than a little sad that pylint doesn't seem to be moving to python 3
    >> in any big hurry.
    >>
    >>
    >> --
    >> http://mail.python.org/mailman/listinfo/python-list
    >>
    >>

    >
    >
    >
    News123, Aug 1, 2010
    #5
  6. wheres pythonmonks

    Matteo Landi Guest

    On Sun, Aug 1, 2010 at 12:27 PM, News123 <> wrote:
    > Hi,
    >
    >
    > On 07/31/2010 11:04 AM, Matteo Landi wrote:
    >> What are the messages one should really care about while evaluating
    >> its code using pylint? It's easy to get 5 scored with a "lot of public
    >> methods" or bad named variables such as 'x' or 'y' .. Have you got any
    >> config file to share?

    >
    >
    > The most important ones are of course the errors.
    > Some of them might be false, but in our team we agreed, that no file is
    > allowed to report pylint errors.
    > This means
    > - just fixing errors (in most cases)
    > - rewriting code (in a few cases)
    > - masking errors with pylint directives in the source (some other few
    > errrors)
    >
    >
    >
    >
    > If you only want to see the errros, then just run
    > pylint -E filename.py
    >
    > Note: This is a rather new but very useful switch.. It doesn't exist
    >    on Ubuntu 10.4's release pylint 0.19.0, but exists on pylint 0.21.1
    >
    >
    >
    > Apart from that. You should discuss within your team, which
    > errors you'd like to have ignored and adapt the pylintrc. This
    > is a rather personal decision.
    > For one project we disiabled for example following warnings:
    > ## C0322 = "Operator not preceded by a space"
    > ## C0323 = "Operator not followed by a space"
    > ## C0324 = "Comma not followed by a space"
    > As we did not have time to rewrite all of the existing code, that
    > violated these rules.
    > We prefered to 'hide' these warnings in order to sett the more important
    > ones.
    >
    > On another new project however we did NOT comment therese rules
    > and decided, that all new code should follow these rules
    >
    >
    > We disabled some special global variables, which we'd like to have in
    > lower case
    >
    > const-rgx ==((specialvar)|(v_[a-z_][a-z0-9_]*)|([A-Z_][A-Z0-9_]*)|(__..*__))$
    >
    >
    > you could also modify variables like
    > # Maximum number of attributes for a class (see R0902).
    > max-attributes=7
    >
    > # Minimum number of public methods for a class (see R0903).
    > min-public-methods=2
    >
    > # Maximum number of public methods for a class (see R0904).
    > max-public-methods=20
    >
    >
    > For some graphics module functions for example we wanted to
    > be allowed to use variable names like x,y as they are
    > completely meaningful names for pixel coordinates.
    >
    >
    > so change the entry good-names
    > good-names=x,y,ex,Run,_


    Thank you so much, these are very precious settings.

    >
    >
    > Hope, that this gave you some ideas
    >
    >
    >
    >>
    >> On Sat, Jul 31, 2010 at 2:48 AM, Dan Stromberg <> wrote:
    >>>
    >>> On Fri, Jul 30, 2010 at 12:18 PM, News123 <> wrote:
    >>>>
    >>>> On 07/30/2010 03:12 PM, wheres pythonmonks wrote:
    >>>>> I am starting to use pylint to look at my code and I see that it gives a
    >>>>> rating.
    >>>>> What values do experienced python programmers get on code not
    >>>>> targeting the benchmark?
    >>>>>
    >>>>> I wrote some code, tried to keep it under 80 characters per line,
    >>>>> reasonable variable names, and I got:
    >>>>>
    >>>>> 0.12 / 10.
    >>>>>
    >>>>> Is this a good score for one not targeting the benchmark?  (pylint
    >>>>> running in default mode)
    >>>>>
    >>>> It's not a goodf core, but arrives easily if you never ran pylint before.
    >>>> With very little effort you should be able to be above 5
    >>>> with a little more effort above 7
    >>>>
    >>>>
    >>>>> Somewhat related:  Is the backslash the only way to extend arguments
    >>>>> to statements over multiple lines?  (e.g.)
    >>>>
    >>>> if you have an opening parenthesis, or bracked, then you don't need a
    >>>> backslash
    >>>>
    >>>> so instead of
    >>>> if longlonglonglonglonglonglonglongvar == \
    >>>>        otherlonglonglonglongvar:
    >>>>
    >>>> you could also write:
    >>>>
    >>>> if (longlonglonglonglonglonglonglongvar ==
    >>>>        otherlonglonglonglongvar):
    >>>>
    >>>>
    >>>> same works of course with asserts.
    >>>>
    >>>>>
    >>>>>>>> def f(x,y,z): return(x+y+z);
    >>>>> ...
    >>>>>>>> f(1,2,
    >>>>> ... 3)
    >>>>> 6
    >>>>>>>> assert f(1,2,3)>0,
    >>>>>   File "<stdin>", line 1
    >>>>>     assert f(1,2,3)>0,
    >>>>>                      ^
    >>>>> SyntaxError: invalid syntax
    >>>>>>>>
    >>>>>
    >>>>> In the above, I could split the arguments to f (I guess b/c of the
    >>>>> parens) but not for assert.  I could use a backslash, but I find this
    >>>>> ugly -- it that my only (best?) option?
    >>>>>
    >>>>> [I really like to assert my code to correctness and I like using the
    >>>>> second argument to assert, but this resulted in a lot of long lines
    >>>>> that I was unable to break except with an ugly backslash.]
    >>>>>
    >>>>> W
    >>>>
    >>> IMO, the important thing about pylint's scoring is that it's but one way of
    >>> many of producing good Python code.  However, it's also one of the easier
    >>> ways of producing good python code.
    >>> I personally like to get my scores up near 10, by annotating in comments
    >>> about the few things that pylint flags that I can't just code around.  This
    >>> requires jumping through some slightly silly hoops (EG the previously
    >>> mentioned "too few public methods", which my various container classes
    >>> always trip over), but going through this process is worthwhile for
    >>> highlighting the hoops pylint can detect that -aren't- so silly.
    >>> The one thing I like to leave unfixed is FIXME's - otherwise my preference
    >>> would be to go for a score of 10 for production code.
    >>> I also like to create a ./this-pylint script for my various projects, that
    >>> have global overrides - things like identifier rules, line length, and....  I
    >>> don't get blanks instead of tabs.  Blanks are fine if you don't understand
    >>> tabs (or think someone in the future who doesn't understand tabs will need
    >>> to work on your code), but tabs allow everyone to see code indented the way
    >>> -they- want to see it, not just the way the original author wanted to see
    >>> it.
    >>> This script (./this-pylint) will also save output from the test in a text
    >>> file, for make (or other dependency handling program) to use to avoid
    >>> re-pylint'ing unmodified code.  It'll give an error typically, if pytlint
    >>> detects any errors other than FIXME's (excluding ones, as I mentioned
    >>> before, that have a comment disabling the warning, of course).
    >>> I'm more than a little sad that pylint doesn't seem to be moving to python 3
    >>> in any big hurry.
    >>>
    >>>
    >>> --
    >>> http://mail.python.org/mailman/listinfo/python-list
    >>>
    >>>

    >>
    >>
    >>

    >
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >




    --
    Matteo Landi
    http://www.matteolandi.net/
    Matteo Landi, Aug 6, 2010
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ad
    Replies:
    2
    Views:
    363
    Brock Allen
    May 16, 2005
  2. Zhi Min
    Replies:
    0
    Views:
    390
    Zhi Min
    Jun 11, 2004
  3. judith
    Replies:
    9
    Views:
    836
    Ian Wilson
    Nov 16, 2006
  4. jocknerd
    Replies:
    4
    Views:
    250
    Gabriel Genellina
    May 2, 2007
  5. Giacomo Boffi
    Replies:
    4
    Views:
    1,627
    Jean-Michel Pichavant
    Apr 19, 2010
Loading...

Share This Page