On Tue, Aug 18, 2015 at 3:00 PM, Claudiu Popa 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

On Tue, Aug 18, 2015 at 5:00 PM, Claudiu Popa 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 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 wrote:

On 18 août 20:35, Skip Montanaro wrote:

...

On Tue, Aug 18, 2015 at 5:00 PM, Claudiu Popa 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 Sat, Aug 22, 2015 at 5:16 AM, Claudiu Popa 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:39 AM, Sylvain Thénault 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

Am 19.08.15 um 03:35 schrieb Skip Montanaro:

On Tue, Aug 18, 2015 at 5:00 PM, Claudiu Popa 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