Hello, For quite some time, since the very first 'Forget the past' commit I have access to, pylint had the ability of providing additional reports, such as Global evaluation, Messages by category, Statistics by type etc. For those of you who are unfamiliar with them, they look like this http://paste.openstack.org/show/421040/ pylint provides an easy way to disable them, by using the --reports flag, as in `--reports=y|n`. After using pylint for some time, they're started to feel useless for me and I'm always disabling them when running pylint. They don't provide that much value, except maybe scaring new users with all sorts of numbers, percentages and negative scores (yes, the default formula allows the global evaluation score to become negative). For pylint users, what do you think about the removal of these reports from pylint? Would it cause problems for you? Are these reports in any sense useful for you? If there's no negative push-back, we'll go through the normal deprecation procedures, so they won't be removed until two releases for now or until Pylint 2.0. As a benefit, we'll get rid of a lot of code that no one is happy to maintain and the maintainers can focus on developing the analysis capabilities instead. Thank you, Claudiu
On Tue, Aug 18, 2015 at 3:00 PM, Claudiu Popa <pcmanticore@gmail.com> wrote:
Hello,
For quite some time, since the very first 'Forget the past' commit I have access to, pylint had the ability of providing additional reports, such as Global evaluation, Messages by category, Statistics by type etc. For those of you who are unfamiliar with them, they look like this http://paste.openstack.org/show/421040/ pylint provides an easy way to disable them, by using the --reports flag, as in `--reports=y|n`.
After using pylint for some time, they're started to feel useless for me and I'm always disabling them when running pylint.
Likewise. They are always the first thing I disable when setting up a pylint.rc file, and I am perpetually annoyed when I forget to include "-r n" when pylinting a one-off script via terminal.
They don't provide that much value, except maybe scaring new users with all sorts of numbers, percentages and negative scores (yes, the default formula allows the global evaluation score to become negative).
For pylint users, what do you think about the removal of these reports from pylint?
Yes please. Or at least make it default to disabled instead of enabled.
Would it cause problems for you?
I guess removing the command-line option could break some build scripts, but the fix would be trivial and removing it would still definitely be a net win for me.
Are these reports in any sense useful for you?
No. If I want an overview of or historical trends for pylint errors for a nontrivial project, I use Jenkins' Violations plugin, which doesn't rely on pylint's --report. Cheers, Chris -- http://chrisrebert.com
* Chris Rebert <pycodequal@rebertia.com> [2015-08-18 16:44:20 -0700]:
On Tue, Aug 18, 2015 at 3:00 PM, Claudiu Popa <pcmanticore@gmail.com> wrote:
Hello,
For quite some time, since the very first 'Forget the past' commit I have access to, pylint had the ability of providing additional reports, such as Global evaluation, Messages by category, Statistics by type etc. For those of you who are unfamiliar with them, they look like this http://paste.openstack.org/show/421040/ pylint provides an easy way to disable them, by using the --reports flag, as in `--reports=y|n`.
After using pylint for some time, they're started to feel useless for me and I'm always disabling them when running pylint.
Likewise. They are always the first thing I disable when setting up a pylint.rc file, and I am perpetually annoyed when I forget to include "-r n" when pylinting a one-off script via terminal.
This. :)
Would it cause problems for you?
I guess removing the command-line option could break some build scripts, but the fix would be trivial and removing it would still definitely be a net win for me.
Hopefully the deprecation would help with that - other than that, it might make sense to keep -r/--reports as valid but ignore it?
Are these reports in any sense useful for you?
As discussed in IRC: For a non-trivial project they're long[1] and you have to search the actual output in that mess. I use the "lines of code" feature from time to time, but I'm sure I can find another tool which does this for me. [1] http://paste.the-compiler.org/view/892e50d1 Florian -- http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
Florian Bruhin <me@the-compiler.org> writes:
I use the "lines of code" feature from time to time, but I'm sure I can find another tool which does this for me.
For simplicity, breadth, and availability (it's already packaged in Debian), I like the “CLOC” <URL:http://cloc.sourceforge.net/> command-line tool. -- \ “Sittin' on the fence, that's a dangerous course / You can even | `\ catch a bullet from the peace-keeping force” —Dire Straits, | _o__) _Once Upon A Time In The West_ | Ben Finney
As a long time pylint user, certainly have seen this before, never found it particularly useful. In retrospect, a bit of a time waster for the consumer, too! When a novice discovers this feature, they may be misdirected to attempt to make use of it, when independent aggregation and reporting tools that integrate with your VCS or CI are so much more comprehensive. the 'coverage' tool forgoes all this complexity of reporting, yet http://coveralls.io — possibly written in another language all together — performs all such functions perfectly fine. jq
On Aug 18, 2015, at 3:00 PM, Claudiu Popa <pcmanticore@gmail.com> wrote:
Hello,
For quite some time, since the very first 'Forget the past' commit I have access to, pylint had the ability of providing additional reports, such as Global evaluation, Messages by category, Statistics by type etc. For those of you who are unfamiliar with them, they look like this http://paste.openstack.org/show/421040/ pylint provides an easy way to disable them, by using the --reports flag, as in `--reports=y|n`.
After using pylint for some time, they're started to feel useless for me and I'm always disabling them when running pylint. They don't provide that much value, except maybe scaring new users with all sorts of numbers, percentages and negative scores (yes, the default formula allows the global evaluation score to become negative).
For pylint users, what do you think about the removal of these reports from pylint? Would it cause problems for you? Are these reports in any sense useful for you?
If there's no negative push-back, we'll go through the normal deprecation procedures, so they won't be removed until two releases for now or until Pylint 2.0. As a benefit, we'll get rid of a lot of code that no one is happy to maintain and the maintainers can focus on developing the analysis capabilities instead.
Thank you, Claudiu _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
On Tue, Aug 18, 2015 at 5:00 PM, Claudiu Popa <pcmanticore@gmail.com> wrote:
For pylint users, what do you think about the removal of these reports from pylint? Would it cause problems for you? Are these reports in any sense useful for you?
No problem removing them. Not really useful in my experience, except very rarely as a relative indicator of the direction things are moving. As a corollary, I will note that some users where I work seemed mesmerized by high scores (10/10, etc) and relied on them, not being aware that pylint wasn't some all-seeing-all-knowing Python code genie. I tried to disabuse them of that notion. I think it would be better to remove them and make people (especially Python newbies) focus on individual messages. Skip
On 18 août 20:35, Skip Montanaro wrote:
On Tue, Aug 18, 2015 at 5:00 PM, Claudiu Popa <pcmanticore@gmail.com> wrote:
For pylint users, what do you think about the removal of these reports from pylint? Would it cause problems for you? Are these reports in any sense useful for you?
No problem removing them. Not really useful in my experience, except very rarely as a relative indicator of the direction things are moving.
As a corollary, I will note that some users where I work seemed mesmerized by high scores (10/10, etc) and relied on them, not being aware that pylint wasn't some all-seeing-all-knowing Python code genie. I tried to disabuse them of that notion. I think it would be better to remove them and make people (especially Python newbies) focus on individual messages.
though that's a point advanced python/pylint users shouldn't ignore. In my experience, the score mecanism of pylint has catched a lot of new comers' attention and, as Skip mentioned, magnetized most of them through the wish of getting an higher score. This is also useful for "smoke test" in CI tools ("pylint score must be greater than 8"). So while a agree most other reports could be disabled by default, and probably simply dropped, I wish to keep this distinguishing feature, and even think it should still be activated by default. -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) 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
On Wed, Aug 19, 2015 at 12:46 AM, Sylvain Thénault <sylvain.thenault@logilab.fr> wrote:
On 18 août 20:35, Skip Montanaro wrote:
On Tue, Aug 18, 2015 at 5:00 PM, Claudiu Popa <pcmanticore@gmail.com> wrote:
For pylint users, what do you think about the removal of these reports from pylint? Would it cause problems for you? Are these reports in any sense useful for you?
No problem removing them. Not really useful in my experience, except very rarely as a relative indicator of the direction things are moving.
As a corollary, I will note that some users where I work seemed mesmerized by high scores (10/10, etc) and relied on them, not being aware that pylint wasn't some all-seeing-all-knowing Python code genie. I tried to disabuse them of that notion. I think it would be better to remove them and make people (especially Python newbies) focus on individual messages.
though that's a point advanced python/pylint users shouldn't ignore. In my experience, the score mecanism of pylint has catched a lot of new comers' attention and, as Skip mentioned, magnetized most of them through the wish of getting an higher score. This is also useful for "smoke test" in CI tools ("pylint score must be greater than 8").
So while a agree most other reports could be disabled by default, and probably simply dropped, I wish to keep this distinguishing feature, and even think it should still be activated by default.
I'm not a PyLint user (so I'm not very familiar with it), so my thoughts below are merely based on Sylvain and Cara's comments. I think the deprecation path might look like providing a way for people to register reports as third party plugins. PyLint can provide an entry-point and then pass in the results so the report plugin can generate a report. PyLint can either take the approach of "you installed it so it's on by default" or all users to select which reports to show. This will definitely be much less code, and will allow PyLint to say "we're deprecating these reports, if you want them to continue working, please take the code and maintain it in a third-party plugin registered on PyPI". People seem to use different reports so this seems fair: allow the people who are interested in those reports to maintain them. This achieves the goal of removing the reports from PyLint itself, thus relieving your maintenance burden while not depriving users of reports. I'd be happy to help with adding entry-points to PyLint for reports if it doesn't already have them. As an aside, any users who want to maintain a third-party plugin like this are welcome to do so in the PyCQA organizations on GitHub or GitLab (or we could make a group for BitBucket too if the maintainer(s) would prefer mercurial). Cheers, Ian
On Wed, Aug 19, 2015 at 5:15 PM, Ian Cordasco <graffatcolmingov@gmail.com> wrote:
On Wed, Aug 19, 2015 at 12:46 AM, Sylvain Thénault <sylvain.thenault@logilab.fr> wrote:
On 18 août 20:35, Skip Montanaro wrote:
On Tue, Aug 18, 2015 at 5:00 PM, Claudiu Popa <pcmanticore@gmail.com> wrote:
For pylint users, what do you think about the removal of these reports from pylint? Would it cause problems for you? Are these reports in any sense useful for you?
No problem removing them. Not really useful in my experience, except very rarely as a relative indicator of the direction things are moving.
As a corollary, I will note that some users where I work seemed mesmerized by high scores (10/10, etc) and relied on them, not being aware that pylint wasn't some all-seeing-all-knowing Python code genie. I tried to disabuse them of that notion. I think it would be better to remove them and make people (especially Python newbies) focus on individual messages.
though that's a point advanced python/pylint users shouldn't ignore. In my experience, the score mecanism of pylint has catched a lot of new comers' attention and, as Skip mentioned, magnetized most of them through the wish of getting an higher score. This is also useful for "smoke test" in CI tools ("pylint score must be greater than 8").
So while a agree most other reports could be disabled by default, and probably simply dropped, I wish to keep this distinguishing feature, and even think it should still be activated by default.
Thank you all for your responses, As it seems, a couple of the reports are actually useful for some of you and they tend to be used differently.
I think the deprecation path might look like providing a way for people to register reports as third party plugins. PyLint can provide an entry-point and then pass in the results so the report plugin can generate a report. PyLint can either take the approach of "you installed it so it's on by default" or all users to select which reports to show. This will definitely be much less code, and will allow PyLint to say "we're deprecating these reports, if you want them to continue working, please take the code and maintain it in a third-party plugin registered on PyPI". People seem to use different reports so this seems fair: allow the people who are interested in those reports to maintain them. This achieves the goal of removing the reports from PyLint itself, thus relieving your maintenance burden while not depriving users of reports. I'd be happy to help with adding entry-points to PyLint for reports if it doesn't already have them.
I'm really enjoying this idea of providing entry-points for Pylint's reports. Currently we have a way to customize the format of the reporting, either it be text, html, json or anything else that the user needs, but no way of providing a hook into pylint's analysis for generating reports such as the ones we have right now. They're currently "hardcoded" and entwined within pylint's internals. Ian, I'll appreciate your help on this one. Most probably, after having this mechanism, the reports will be moved into a third party package, which can be activated on a need by need basis, so that no one loses the current functionality if they're using it and no one needs to install third party reports if they don't need reports at all.
As an aside, any users who want to maintain a third-party plugin like this are welcome to do so in the PyCQA organizations on GitHub or GitLab (or we could make a group for BitBucket too if the maintainer(s) would prefer mercurial).
Having a group for BitBucket as well would be great, pylint could be part of it. Unfortunately, I don't think switching to github could work for us (I'm enjoying mercurial more). Thank you, Claudiu
On Sat, Aug 22, 2015 at 5:16 AM, Claudiu Popa <pcmanticore@gmail.com> wrote:
On Wed, Aug 19, 2015 at 5:15 PM, Ian Cordasco
I think the deprecation path might look like providing a way for people to register reports as third party plugins. PyLint can provide an entry-point and then pass in the results so the report plugin can generate a report. PyLint can either take the approach of "you installed it so it's on by default" or all users to select which reports to show. This will definitely be much less code, and will allow PyLint to say "we're deprecating these reports, if you want them to continue working, please take the code and maintain it in a third-party plugin registered on PyPI". People seem to use different reports so this seems fair: allow the people who are interested in those reports to maintain them. This achieves the goal of removing the reports from PyLint itself, thus relieving your maintenance burden while not depriving users of reports. I'd be happy to help with adding entry-points to PyLint for reports if it doesn't already have them.
I'm really enjoying this idea of providing entry-points for Pylint's reports. Currently we have a way to customize the format of the reporting, either it be text, html, json or anything else that the user needs, but no way of providing a hook into pylint's analysis for generating reports such as the ones we have right now. They're currently "hardcoded" and entwined within pylint's internals. Ian, I'll appreciate your help on this one.
I'm happy to help! I may bug you for Mercurial help because it's been a *long* time since I've used it. :D
Most probably, after having this mechanism, the reports will be moved into a third party package, which can be activated on a need by need basis, so that no one loses the current functionality if they're using it and no one needs to install third party reports if they don't need reports at all.
As an aside, any users who want to maintain a third-party plugin like this are welcome to do so in the PyCQA organizations on GitHub or GitLab (or we could make a group for BitBucket too if the maintainer(s) would prefer mercurial).
Having a group for BitBucket as well would be great, pylint could be part of it. Unfortunately, I don't think switching to github could work for us (I'm enjoying mercurial more).
The group is now here: https://bitbucket.org/pycqa/ and I made you an administrator right off the bat so you can do whatever you need. Naturally, there's no pressure to move PyLint over there, but it would be pretty cool to have a gigantic collection of these tools under one umbrella. As a side note, in the interest of transparency, Ian Lee (the pep8 maintainer) is an Admin on the GitHub organization as well. We had discussed this previously off-list but I never did it until now and thought y'all would like to know.
On 22 août 08:14, Ian Cordasco wrote:
The group is now here: https://bitbucket.org/pycqa/ and I made you an administrator right off the bat so you can do whatever you need.
Claudiu, would you add me there please? -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) 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
On Mon, Aug 24, 2015 at 9:40 AM, Sylvain Thénault <sylvain.thenault@logilab.fr> wrote:
On 22 août 08:14, Ian Cordasco wrote:
The group is now here: https://bitbucket.org/pycqa/ and I made you an administrator right off the bat so you can do whatever you need.
Claudiu, would you add me there please?
Added.
On 22 août 13:16, Claudiu Popa wrote:
I'm really enjoying this idea of providing entry-points for Pylint's reports. Currently we have a way to customize the format of the reporting, either it be text, html, json or anything else that the user needs, but no way of providing a hook into pylint's analysis for generating reports such as the ones we have right now. They're currently "hardcoded" and entwined within pylint's internals. Ian, I'll appreciate your help on this one.
I'm not sure about what you want here. Reports are currently declarated by checkers, because they usually rely on data gathered using the checker API. Do you mean we should avoid checker that mix actual checks and data gathering for reports?
Most probably, after having this mechanism, the reports will be moved into a third party package, which can be activated on a need by need basis, so that no one loses the current functionality if they're using it and no one needs to install third party reports if they don't need reports at all.
I'm fine with that, though I still think the note thing should be kept activated by default, especially for new comers. This could be as simple as one extra line at the end of the analysis. -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) 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
On Mon, Aug 24, 2015 at 9:39 AM, Sylvain Thénault <sylvain.thenault@logilab.fr> wrote:
On 22 août 13:16, Claudiu Popa wrote:
I'm really enjoying this idea of providing entry-points for Pylint's reports. Currently we have a way to customize the format of the reporting, either it be text, html, json or anything else that the user needs, but no way of providing a hook into pylint's analysis for generating reports such as the ones we have right now. They're currently "hardcoded" and entwined within pylint's internals. Ian, I'll appreciate your help on this one.
I'm not sure about what you want here. Reports are currently declarated by checkers, because they usually rely on data gathered using the checker API. Do you mean we should avoid checker that mix actual checks and data gathering for reports?
The initial problem occurred when I looked into removing logilab-common as a dependency for pylint. The only dependent modules left were components used by the reports and the cohesion with logilab.common is so high, that it is a real pain to remove the dependency right now. Instead, if we'll have some hooks into the reporting checkers, then the dependency can be moved outside of the project, into third party utilities.
Most probably, after having this mechanism, the reports will be moved into a third party package, which can be activated on a need by need basis, so that no one loses the current functionality if they're using it and no one needs to install third party reports if they don't need reports at all.
I'm fine with that, though I still think the note thing should be kept activated by default, especially for new comers. This could be as simple as one extra line at the end of the analysis.
The note will remain, it's especially useful for newcomers. /Claudiu
On 24 août 09:49, Claudiu Popa wrote:
On Mon, Aug 24, 2015 at 9:39 AM, Sylvain Thénault <sylvain.thenault@logilab.fr> wrote:
On 22 août 13:16, Claudiu Popa wrote:
I'm really enjoying this idea of providing entry-points for Pylint's reports. Currently we have a way to customize the format of the reporting, either it be text, html, json or anything else that the user needs, but no way of providing a hook into pylint's analysis for generating reports such as the ones we have right now. They're currently "hardcoded" and entwined within pylint's internals. Ian, I'll appreciate your help on this one.
I'm not sure about what you want here. Reports are currently declarated by checkers, because they usually rely on data gathered using the checker API. Do you mean we should avoid checker that mix actual checks and data gathering for reports?
The initial problem occurred when I looked into removing logilab-common as a dependency for pylint. The only dependent modules left were components used by the reports and the cohesion with logilab.common is so high, that it is a real pain to remove the dependency right now. Instead, if we'll have some hooks into the reporting checkers, then the dependency can be moved outside of the project, into third party utilities.
Ah so you mean the ureport thing? This is there only to support report in different formats (mainly text and html).
Most probably, after having this mechanism, the reports will be moved into a third party package, which can be activated on a need by need basis, so that no one loses the current functionality if they're using it and no one needs to install third party reports if they don't need reports at all.
I'm fine with that, though I still think the note thing should be kept activated by default, especially for new comers. This could be as simple as one extra line at the end of the analysis.
The note will remain, it's especially useful for newcomers.
Glad we agree on that :) -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) 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
Am 19.08.15 um 03:35 schrieb Skip Montanaro:
On Tue, Aug 18, 2015 at 5:00 PM, Claudiu Popa <pcmanticore@gmail.com <mailto:pcmanticore@gmail.com>> wrote:
For pylint users, what do you think about the removal of these reports from pylint? Would it cause problems for you? Are these reports in any sense useful for you?
No problem removing them. Not really useful in my experience, except very rarely as a relative indicator of the direction things are moving.
As a corollary, I will note that some users where I work seemed mesmerized by high scores (10/10, etc) and relied on them, not being aware that pylint wasn't some all-seeing-all-knowing Python code genie. I tried to disabuse them of that notion. I think it would be better to remove them and make people (especially Python newbies) focus on individual messages.
As a Python trainer, I do have contact with many Python beginners. I use pylint in all of my introductory and many of my more advanced courses. Based on feedback from these users, I would suggest: 1. Make all these long-winded metrics and other reports optional, i.e. not default. 2. Keep the score. The score makes it a bit like a game. People really have fun with it. I think for the most part this is a good thing. Of course, there are always a few people who put too much emphasis on the score. But I think the advantages of the score are much bigger the disadvantages. Mike
Skip
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
participants (9)
-
Ben Finney -
Chris Rebert -
Claudiu Popa -
Florian Bruhin -
Ian Cordasco -
Jeff Quast -
Mike Müller -
Skip Montanaro -
Sylvain Thénault