pylint scores
in [Python]
|
Prev: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?
Next: how to build same executabl with andwithout console output
From: wheres pythonmonks on 30 Jul 2010 09:12 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
From: News123 on 30 Jul 2010 15:18 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
From: Matteo Landi on 31 Jul 2010 05:04 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 <drsalists(a)gmail.com> wrote: > > On Fri, Jul 30, 2010 at 12:18 PM, News123 <news1234(a)free.fr> 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/
From: News123 on 1 Aug 2010 06:27 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 <drsalists(a)gmail.com> wrote: >> >> On Fri, Jul 30, 2010 at 12:18 PM, News123 <news1234(a)free.fr> 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 >> >> > > >
From: Matteo Landi on 6 Aug 2010 08:49
On Sun, Aug 1, 2010 at 12:27 PM, News123 <news1234(a)free.fr> 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 <drsalists(a)gmail.com> wrote: >>> >>> On Fri, Jul 30, 2010 at 12:18 PM, News123 <news1234(a)free.fr> 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/ |