On Wed, Aug 19, 2015 at 5:15 PM, Ian Cordasco
<graffatcolmin...@gmail.com> wrote:
> On Wed, Aug 19, 2015 at 12:46 AM, Sylvain Thénault
> <sylvain.thena...@logilab.fr> wrote:
>> On 18 août 20:35, Skip Montanaro wrote:
>>> On Tue, Aug 18, 2015 at 5:00 PM, Claudiu Popa <pcmantic...@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
_______________________________________________
code-quality mailing list
code-quality@python.org
https://mail.python.org/mailman/listinfo/code-quality
