From paul at grammatech.com  Mon Sep  3 10:59:45 2018
From: paul at grammatech.com (Paul Anderson)
Date: Mon, 3 Sep 2018 10:59:45 -0400
Subject: [code-quality] Pylint and SARIF
Message-ID: <64beee15-01d2-c923-cd3b-39c998040c04@grammatech.com>

Hello everyone!

This is my first post to this list, so first, let me give a quick 
introduction. I'm VP of Engineering at GrammaTech, where I am in charge 
of an advanced static analysis tool named CodeSonar. It primarily works 
for C and C++, but also for x86, x64 and ARM binaries. We cover other 
languages by integrating with other tools (mostly open source). We don't 
have an integration with Pylint yet, but that's coming as described below.

I'm writing to let the community know of some work we will be doing that 
should benefit everyone. I think I know the best way forward, but I'd 
appreciate any words of wisdom and feedback on our approach.

SARIF stands for Static Analysis Results Interchange Format. It is a new 
standard that originated at Microsoft, and that is now under the OASIS 
umbrella (I'm on the TC): 
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif. The 
idea is to make it easier for tools that produce results to integrate 
with tools that consume results. Our own tool is both a producer and a 
consumer. That is, it can import results from SARIF-compatible tools and 
show them it is user interface. Our strategy to make CodeSonar be useful 
for other languages is through SARIF; we'll write converters to SARIF 
for the best-of-breed tools.

Consequently, we are planning to make it so that Pylint can produce 
SARIF. There are two good ways to do this.

1. The easiest thing to do is to simply run "pylint -f json ..." and 
write a simple program to convert the output to SARIF (data from "pylint 
--list-msgs" is also needed). We're doing this first. A nice thing about 
this approach is that it doesn't require any changes to Pylint. The 
disadvantage is that it's likely to be very sensitive to the particular 
version of Pylint used. E.g., if the format of those outputs change. The 
plan is to contribute this to the sarif SDK github.

2. The better long-term approach is to change pylint to add a new output 
format so one can do "pylint -f sarif ...". This way, everyone gets it. 
I'm not expecting this to be too difficult, although I concede that I 
haven't scrutinized the pylint code enough to know for sure.

I'm expecting #1 to appear within a couple of weeks, and to start work 
on #2 by the end of the month. I'd appreciate any input from interested 
parties.

Thanks,

-Paul

-- 
Paul Anderson, VP of Engineering, GrammaTech, Inc.
531 Esty St., Ithaca, NY 14850
Tel: +1 607 273-7340 x118; http://www.grammatech.com


From pcmanticore at gmail.com  Mon Sep  3 11:25:30 2018
From: pcmanticore at gmail.com (Claudiu Popa)
Date: Mon, 3 Sep 2018 17:25:30 +0200
Subject: [code-quality] Pylint and SARIF
In-Reply-To: <64beee15-01d2-c923-cd3b-39c998040c04@grammatech.com>
References: <64beee15-01d2-c923-cd3b-39c998040c04@grammatech.com>
Message-ID: <CAMy=CLoP+964VyDpui79mBXtsEmXvO2UDZDXZEGBokHbaDMBug@mail.gmail.com>

Hi Paul,

Nice to meet you.
Thank you for that link, I wasn't aware of this new standard.
It would be great to support it for pylint as well, and most likely
shouldn't be too difficult to add a custom reporter in the same vein
as the JSON reporter.
You can find some examples here:
https://github.com/PyCQA/pylint/tree/master/pylint/reporters

Cheers,
Claudiu

On 3 September 2018 at 16:59, Paul Anderson <paul at grammatech.com> wrote:
> Hello everyone!
>
> This is my first post to this list, so first, let me give a quick
> introduction. I'm VP of Engineering at GrammaTech, where I am in charge of
> an advanced static analysis tool named CodeSonar. It primarily works for C
> and C++, but also for x86, x64 and ARM binaries. We cover other languages by
> integrating with other tools (mostly open source). We don't have an
> integration with Pylint yet, but that's coming as described below.
>
> I'm writing to let the community know of some work we will be doing that
> should benefit everyone. I think I know the best way forward, but I'd
> appreciate any words of wisdom and feedback on our approach.
>
> SARIF stands for Static Analysis Results Interchange Format. It is a new
> standard that originated at Microsoft, and that is now under the OASIS
> umbrella (I'm on the TC):
> https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif. The idea
> is to make it easier for tools that produce results to integrate with tools
> that consume results. Our own tool is both a producer and a consumer. That
> is, it can import results from SARIF-compatible tools and show them it is
> user interface. Our strategy to make CodeSonar be useful for other languages
> is through SARIF; we'll write converters to SARIF for the best-of-breed
> tools.
>
> Consequently, we are planning to make it so that Pylint can produce SARIF.
> There are two good ways to do this.
>
> 1. The easiest thing to do is to simply run "pylint -f json ..." and write a
> simple program to convert the output to SARIF (data from "pylint
> --list-msgs" is also needed). We're doing this first. A nice thing about
> this approach is that it doesn't require any changes to Pylint. The
> disadvantage is that it's likely to be very sensitive to the particular
> version of Pylint used. E.g., if the format of those outputs change. The
> plan is to contribute this to the sarif SDK github.
>
> 2. The better long-term approach is to change pylint to add a new output
> format so one can do "pylint -f sarif ...". This way, everyone gets it. I'm
> not expecting this to be too difficult, although I concede that I haven't
> scrutinized the pylint code enough to know for sure.
>
> I'm expecting #1 to appear within a couple of weeks, and to start work on #2
> by the end of the month. I'd appreciate any input from interested parties.
>
> Thanks,
>
> -Paul
>
> --
> Paul Anderson, VP of Engineering, GrammaTech, Inc.
> 531 Esty St., Ithaca, NY 14850
> Tel: +1 607 273-7340 x118; http://www.grammatech.com
>
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality

From graffatcolmingov at gmail.com  Mon Sep  3 12:47:13 2018
From: graffatcolmingov at gmail.com (Ian Stapleton Cordasco)
Date: Mon, 3 Sep 2018 11:47:13 -0500
Subject: [code-quality] Pylint and SARIF
In-Reply-To: <CAMy=CLoP+964VyDpui79mBXtsEmXvO2UDZDXZEGBokHbaDMBug@mail.gmail.com>
References: <64beee15-01d2-c923-cd3b-39c998040c04@grammatech.com>
 <CAMy=CLoP+964VyDpui79mBXtsEmXvO2UDZDXZEGBokHbaDMBug@mail.gmail.com>
Message-ID: <CAN-Kwu2qb_e8_VJCKeVygFwK_M=g9YzneCJ3HNyoWbav5RcL9w@mail.gmail.com>

I think Bandit (https://github.com/pycqa/bandit) is another project we
should add this to, as well as Flake8
On Mon, Sep 3, 2018 at 10:25 AM Claudiu Popa <pcmanticore at gmail.com> wrote:
>
> Hi Paul,
>
> Nice to meet you.
> Thank you for that link, I wasn't aware of this new standard.
> It would be great to support it for pylint as well, and most likely
> shouldn't be too difficult to add a custom reporter in the same vein
> as the JSON reporter.
> You can find some examples here:
> https://github.com/PyCQA/pylint/tree/master/pylint/reporters
>
> Cheers,
> Claudiu
>
> On 3 September 2018 at 16:59, Paul Anderson <paul at grammatech.com> wrote:
> > Hello everyone!
> >
> > This is my first post to this list, so first, let me give a quick
> > introduction. I'm VP of Engineering at GrammaTech, where I am in charge of
> > an advanced static analysis tool named CodeSonar. It primarily works for C
> > and C++, but also for x86, x64 and ARM binaries. We cover other languages by
> > integrating with other tools (mostly open source). We don't have an
> > integration with Pylint yet, but that's coming as described below.
> >
> > I'm writing to let the community know of some work we will be doing that
> > should benefit everyone. I think I know the best way forward, but I'd
> > appreciate any words of wisdom and feedback on our approach.
> >
> > SARIF stands for Static Analysis Results Interchange Format. It is a new
> > standard that originated at Microsoft, and that is now under the OASIS
> > umbrella (I'm on the TC):
> > https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif. The idea
> > is to make it easier for tools that produce results to integrate with tools
> > that consume results. Our own tool is both a producer and a consumer. That
> > is, it can import results from SARIF-compatible tools and show them it is
> > user interface. Our strategy to make CodeSonar be useful for other languages
> > is through SARIF; we'll write converters to SARIF for the best-of-breed
> > tools.
> >
> > Consequently, we are planning to make it so that Pylint can produce SARIF.
> > There are two good ways to do this.
> >
> > 1. The easiest thing to do is to simply run "pylint -f json ..." and write a
> > simple program to convert the output to SARIF (data from "pylint
> > --list-msgs" is also needed). We're doing this first. A nice thing about
> > this approach is that it doesn't require any changes to Pylint. The
> > disadvantage is that it's likely to be very sensitive to the particular
> > version of Pylint used. E.g., if the format of those outputs change. The
> > plan is to contribute this to the sarif SDK github.
> >
> > 2. The better long-term approach is to change pylint to add a new output
> > format so one can do "pylint -f sarif ...". This way, everyone gets it. I'm
> > not expecting this to be too difficult, although I concede that I haven't
> > scrutinized the pylint code enough to know for sure.
> >
> > I'm expecting #1 to appear within a couple of weeks, and to start work on #2
> > by the end of the month. I'd appreciate any input from interested parties.
> >
> > Thanks,
> >
> > -Paul
> >
> > --
> > Paul Anderson, VP of Engineering, GrammaTech, Inc.
> > 531 Esty St., Ithaca, NY 14850
> > Tel: +1 607 273-7340 x118; http://www.grammatech.com
> >
> > _______________________________________________
> > code-quality mailing list
> > code-quality at python.org
> > https://mail.python.org/mailman/listinfo/code-quality
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality

From paul at grammatech.com  Mon Sep  3 16:57:14 2018
From: paul at grammatech.com (Paul Anderson)
Date: Mon, 3 Sep 2018 16:57:14 -0400
Subject: [code-quality] Pylint and SARIF
In-Reply-To: <CAMy=CLoP+964VyDpui79mBXtsEmXvO2UDZDXZEGBokHbaDMBug@mail.gmail.com>
References: <64beee15-01d2-c923-cd3b-39c998040c04@grammatech.com>
 <CAMy=CLoP+964VyDpui79mBXtsEmXvO2UDZDXZEGBokHbaDMBug@mail.gmail.com>
Message-ID: <c87b7174-4d25-27a4-d58b-281d2932bd42@grammatech.com>

Claudiu:


On 9/3/2018 11:25 AM, Claudiu Popa wrote:
> Hi Paul,
>
> Nice to meet you.
> Thank you for that link, I wasn't aware of this new standard.
> It would be great to support it for pylint as well, and most likely
> shouldn't be too difficult to add a custom reporter in the same vein
> as the JSON reporter.
> You can find some examples here:
> https://github.com/PyCQA/pylint/tree/master/pylint/reporters
I'll take a look there and let you know if I have any questions.

-Paul
>
> Cheers,
> Claudiu
>
> On 3 September 2018 at 16:59, Paul Anderson <paul at grammatech.com> wrote:
>> Hello everyone!
>>
>> This is my first post to this list, so first, let me give a quick
>> introduction. I'm VP of Engineering at GrammaTech, where I am in charge of
>> an advanced static analysis tool named CodeSonar. It primarily works for C
>> and C++, but also for x86, x64 and ARM binaries. We cover other languages by
>> integrating with other tools (mostly open source). We don't have an
>> integration with Pylint yet, but that's coming as described below.
>>
>> I'm writing to let the community know of some work we will be doing that
>> should benefit everyone. I think I know the best way forward, but I'd
>> appreciate any words of wisdom and feedback on our approach.
>>
>> SARIF stands for Static Analysis Results Interchange Format. It is a new
>> standard that originated at Microsoft, and that is now under the OASIS
>> umbrella (I'm on the TC):
>> https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif. The idea
>> is to make it easier for tools that produce results to integrate with tools
>> that consume results. Our own tool is both a producer and a consumer. That
>> is, it can import results from SARIF-compatible tools and show them it is
>> user interface. Our strategy to make CodeSonar be useful for other languages
>> is through SARIF; we'll write converters to SARIF for the best-of-breed
>> tools.
>>
>> Consequently, we are planning to make it so that Pylint can produce SARIF.
>> There are two good ways to do this.
>>
>> 1. The easiest thing to do is to simply run "pylint -f json ..." and write a
>> simple program to convert the output to SARIF (data from "pylint
>> --list-msgs" is also needed). We're doing this first. A nice thing about
>> this approach is that it doesn't require any changes to Pylint. The
>> disadvantage is that it's likely to be very sensitive to the particular
>> version of Pylint used. E.g., if the format of those outputs change. The
>> plan is to contribute this to the sarif SDK github.
>>
>> 2. The better long-term approach is to change pylint to add a new output
>> format so one can do "pylint -f sarif ...". This way, everyone gets it. I'm
>> not expecting this to be too difficult, although I concede that I haven't
>> scrutinized the pylint code enough to know for sure.
>>
>> I'm expecting #1 to appear within a couple of weeks, and to start work on #2
>> by the end of the month. I'd appreciate any input from interested parties.
>>
>> Thanks,
>>
>> -Paul
>>
>> --
>> Paul Anderson, VP of Engineering, GrammaTech, Inc.
>> 531 Esty St., Ithaca, NY 14850
>> Tel: +1 607 273-7340 x118; http://www.grammatech.com
>>
>> _______________________________________________
>> code-quality mailing list
>> code-quality at python.org
>> https://mail.python.org/mailman/listinfo/code-quality

-- 
Paul Anderson, VP of Engineering, GrammaTech, Inc.
531 Esty St., Ithaca, NY 14850
Tel: +1 607 273-7340 x118; http://www.grammatech.com


From paul at grammatech.com  Mon Sep  3 17:04:02 2018
From: paul at grammatech.com (Paul Anderson)
Date: Mon, 3 Sep 2018 17:04:02 -0400
Subject: [code-quality] Pylint and SARIF
In-Reply-To: <CAN-Kwu2qb_e8_VJCKeVygFwK_M=g9YzneCJ3HNyoWbav5RcL9w@mail.gmail.com>
References: <64beee15-01d2-c923-cd3b-39c998040c04@grammatech.com>
 <CAMy=CLoP+964VyDpui79mBXtsEmXvO2UDZDXZEGBokHbaDMBug@mail.gmail.com>
 <CAN-Kwu2qb_e8_VJCKeVygFwK_M=g9YzneCJ3HNyoWbav5RcL9w@mail.gmail.com>
Message-ID: <0ab700dd-1527-8d9a-5e3e-3fbdc1521d17@grammatech.com>

Ian:

I'll take a look at those too, but I can't promise I'll have the 
bandwidth for them.

-Paul


On 9/3/2018 12:47 PM, Ian Stapleton Cordasco wrote:
> I think Bandit (https://github.com/pycqa/bandit) is another project we
> should add this to, as well as Flake8
> On Mon, Sep 3, 2018 at 10:25 AM Claudiu Popa <pcmanticore at gmail.com> wrote:
>> Hi Paul,
>>
>> Nice to meet you.
>> Thank you for that link, I wasn't aware of this new standard.
>> It would be great to support it for pylint as well, and most likely
>> shouldn't be too difficult to add a custom reporter in the same vein
>> as the JSON reporter.
>> You can find some examples here:
>> https://github.com/PyCQA/pylint/tree/master/pylint/reporters
>>
>> Cheers,
>> Claudiu
>>
>> On 3 September 2018 at 16:59, Paul Anderson <paul at grammatech.com> wrote:
>>> Hello everyone!
>>>
>>> This is my first post to this list, so first, let me give a quick
>>> introduction. I'm VP of Engineering at GrammaTech, where I am in charge of
>>> an advanced static analysis tool named CodeSonar. It primarily works for C
>>> and C++, but also for x86, x64 and ARM binaries. We cover other languages by
>>> integrating with other tools (mostly open source). We don't have an
>>> integration with Pylint yet, but that's coming as described below.
>>>
>>> I'm writing to let the community know of some work we will be doing that
>>> should benefit everyone. I think I know the best way forward, but I'd
>>> appreciate any words of wisdom and feedback on our approach.
>>>
>>> SARIF stands for Static Analysis Results Interchange Format. It is a new
>>> standard that originated at Microsoft, and that is now under the OASIS
>>> umbrella (I'm on the TC):
>>> https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sarif. The idea
>>> is to make it easier for tools that produce results to integrate with tools
>>> that consume results. Our own tool is both a producer and a consumer. That
>>> is, it can import results from SARIF-compatible tools and show them it is
>>> user interface. Our strategy to make CodeSonar be useful for other languages
>>> is through SARIF; we'll write converters to SARIF for the best-of-breed
>>> tools.
>>>
>>> Consequently, we are planning to make it so that Pylint can produce SARIF.
>>> There are two good ways to do this.
>>>
>>> 1. The easiest thing to do is to simply run "pylint -f json ..." and write a
>>> simple program to convert the output to SARIF (data from "pylint
>>> --list-msgs" is also needed). We're doing this first. A nice thing about
>>> this approach is that it doesn't require any changes to Pylint. The
>>> disadvantage is that it's likely to be very sensitive to the particular
>>> version of Pylint used. E.g., if the format of those outputs change. The
>>> plan is to contribute this to the sarif SDK github.
>>>
>>> 2. The better long-term approach is to change pylint to add a new output
>>> format so one can do "pylint -f sarif ...". This way, everyone gets it. I'm
>>> not expecting this to be too difficult, although I concede that I haven't
>>> scrutinized the pylint code enough to know for sure.
>>>
>>> I'm expecting #1 to appear within a couple of weeks, and to start work on #2
>>> by the end of the month. I'd appreciate any input from interested parties.
>>>
>>> Thanks,
>>>
>>> -Paul
>>>
>>> --
>>> Paul Anderson, VP of Engineering, GrammaTech, Inc.
>>> 531 Esty St., Ithaca, NY 14850
>>> Tel: +1 607 273-7340 x118; http://www.grammatech.com
>>>
>>> _______________________________________________
>>> code-quality mailing list
>>> code-quality at python.org
>>> https://mail.python.org/mailman/listinfo/code-quality
>> _______________________________________________
>> code-quality mailing list
>> code-quality at python.org
>> https://mail.python.org/mailman/listinfo/code-quality

-- 
Paul Anderson, VP of Engineering, GrammaTech, Inc.
531 Esty St., Ithaca, NY 14850
Tel: +1 607 273-7340 x118; http://www.grammatech.com


From jreuter at ddn.com  Tue Sep  4 16:44:26 2018
From: jreuter at ddn.com (Jim Reuter)
Date: Tue, 4 Sep 2018 20:44:26 +0000
Subject: [code-quality] pylint suggestion
Message-ID: <BBE28C8D35EDEC48B06294CB3C659727497D8E59@LAX-EX-MB1.datadirect.datadirectnet.com>

Hopefully this is the right place for Pylint suggestions; I did not see any
other mailing lists that appeared to fit.

I am working on a large project with a lot of existing Python code,
and we use pylint in our processes.
One frequently used module has a class with a lot of property methods
and regular methods, e.g.


class Cl(Parent):
    @property
    def thing1(self):
        return calculate_thing1()

    @property
    def test2(self):
        return get_test2()

    def is_fubd(self):
        return some_other_test() == 42


So, naturally, I mistakenly used the last item above as if it was
a property instead of a method:

    if is_fubd:
                do_something()
    else:
                do_something_else()

The code, of course, needs to be:

    if is_fubd():
        ...

The first form is valid code but mostly useless, because the
is_fubd method exists so an 'if' test is always true. And it is
a real pain to find the mistake by inspection.  It would sure
be nice to have pylint flag this usage as suspicious.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20180904/3c5cd196/attachment.html>

From carl.crowder at gmail.com  Wed Sep  5 05:27:15 2018
From: carl.crowder at gmail.com (Carl Crowder)
Date: Wed, 05 Sep 2018 11:27:15 +0200
Subject: [code-quality] pylint suggestion
In-Reply-To: <BBE28C8D35EDEC48B06294CB3C659727497D8E59@LAX-EX-MB1.datadirect.datadirectnet.com>
References: <BBE28C8D35EDEC48B06294CB3C659727497D8E59@LAX-EX-MB1.datadirect.datadirectnet.com>
Message-ID: <c496db0e-fe74-499e-b426-60d97b60c7fe@getmailbird.com>

I think that this would be better a pylint specific issue on github

Also I think this would be quite hard - it seems you want a check that says 'if this is a function that is used in a boolean but it it not called' that seems quite specific and you never know, if it's not a syntax error, perhaps it's legitimately used by someone?

However I defer to the pylint gurus as this is just my conjecture :-)
On 05/09/2018 11:05:21, Jim Reuter <jreuter at ddn.com> wrote:
Hopefully this is the right place for Pylint suggestions; I did not see any
other mailing lists that appeared to fit.
?
I am working on a large project with a lot of existing Python code,
and we use pylint in our processes.
One frequently used module has a class with a lot of property methods
and regular methods, e.g.
?
?
class Cl(Parent):
??? @property
??? def thing1(self):
??????? return calculate_thing1()
?
??? @property
??? def test2(self):
??????? return get_test2()
?
??? def is_fubd(self):
??????? return some_other_test() == 42
?
?
So, naturally, I mistakenly used the last item above as if it was
a property instead of a method:
?
??? if is_fubd:
??????????????? do_something()
??? else:
??????????????? do_something_else()
?
The code, of course, needs to be:
?
??? if is_fubd():
??????? ...
?
The first form is valid code but mostly useless, because the
is_fubd method exists so an 'if' test is always true. And it is
a real pain to find the mistake by inspection.? It would sure
be nice to have pylint flag this usage as suspicious.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20180905/ad8e881b/attachment.html>

From roberto at leinardi.com  Tue Sep 18 07:40:55 2018
From: roberto at leinardi.com (Roberto Leinardi)
Date: Tue, 18 Sep 2018 13:40:55 +0200
Subject: [code-quality] PyLint and Mypy real-time (and on-demand) code
 inspection from within PyCharm/IDEA
Message-ID: <CAEfz6QR6sC0sST2AgrveA_f-2S3CCAWN9bNNzRNvPN2SQGxx=g@mail.gmail.com>

Hello there,

I am the developer of pylint-pycharm and mypy-pycharm, two plugins
providing both real-time and on-demand scanning of Python files with
PyLint/Mypy from within PyCharm/IDEA.

The real-time code inspection works automatically the same way like the
PyCharm's build-in PEP8 check (you see the issues highlighted directly in
your code while typing).

The on-demand inspection has several options that go from just scanning the
current file to scan the entire project.

The plugins also offer an option to run a check on modified files before a
VCS checkin.

If you are familiar with Checkstyle-IDEA plugin for Java, they are very
similar and offer the same features (and share a lot of the code).

The plugins source code is available here:
https://github.com/leinardi/pylint-pycharm
https://github.com/leinardi/mypy-pycharm

But they can also be easily installed from the official JetBrains Plugin
Repository:
1. In PyCharm, open the Settings/Preferences dialog (CTRL+Alt+S), click
Plugins.
2. Click Browse repositories.
3. In the Browse Repositories dialog that opens, right-click on the plugin
named "Pylint" or "Mypy" and select Download and Install.
4. Confirm your intention to download and install the selected plugin.
5. Click Close.
6. Click OK in the Settings dialog and restart PyCharm for the changes to
take effect.

Thanks and enjoy linting!
Roberto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/code-quality/attachments/20180918/5b026727/attachment.html>