[Razze]

I know it's late in the process, but I feel like flake8 is not the tool we want for this job.
As Flake8 says it's for enforcing a style guide (or their website is misleading me), which is not what I want us to do. I want us to primarily point out compile problems and maybe report suchs things as unused imports and real code errors.
It's nice to get nicely formatted code, but I feel like those other problems are far better to tackle.
So can we disable those checks and configure it that it does those things for us?

And yes, you can share the draft, but I won't look at it or comment on it now, as I feel that everybody should have the same chance. And that's going to be when everything is uploaded to the gsoc site.

[gobinath]

Hi,

Of course, Flake8 reports most of the style violations but it does report syntax errors and unused imports.
In my opinion, it is impossible to address runtime errors in a dynamic language like Python without executing every single line in the code. Therefore it is hard or merely impossible to have such a tool.
However, syntax errors which are similar to compile-time errors in other languages can be detected. Flake8 does report such syntax violations.

See below some examples and Flake8 reports:
1.

python:
x = 10

y = 20



print(x y) # Error in this line

bad.py:4:9: E999 SyntaxError: invalid syntax

2.

python:
import os



x = 10

y = 20



print(x + y)

bad.py:1:1: F401 'os' imported but unused

3.

python:
x = 10

y = 20



print(z) # z is not defined

bad.py:4:7: F821 undefined name 'z'

Another benifit of using Flake8 is its plugin support. We can write our own plugins and introduce new rules.
For example, you have opened an issue: #19 Search for print statements and report them which can be simply enabled by installing this plugin: flake8-print
See the flake8-print in action below:

python:
x = 10

y = 20

z = x + y

print(z)

bad.py:4:1: T001 print found.

Flake8 allows to ignore unwanted checks. Therefore, we can configure it to ignore unwanted style checks via a config file (or even hard coded).

[Razze]

Sounds good and it's not about catching everything. Just more then today
Had a submission of my own these days, where I added an additional comma to a line. The reviewer didn't spot it, so users eventually did :/

[gobinath]

Hi,
Could you please share the file which you have tested. I will try on my side to find out a solution.

[Razze]

Heres the code I'm talking about.
This folder has the comma failure
https://github.com/xbmc/repo-plugins/pull/1692

And this is the fix
https://github.com/xbmc/repo-plugins/pul...53ef5eR104

[gobinath]

Hi,
You are right. Flake8 does not catch this problem. However, pylint catch that issue. Pylint also detects example issues I have listed above.
Considering the available list of error messages [1], pylint seems to be a suitable candidate.

Please have a look at the pylint prototype which is testing your plugin.py file with comma: https://github.com/slgobinath/pycode-ana..._pylint.py



FYI:
I also tried Python's built-in source parser which could not detect this problem.

[1] http://pylint-messages.wikidot.com/all-codes

[Razze]

I really like this

[gobinath]

Thanks. I will go with pylint.

How would you like to format the markdown report?
GitHub does not support text color. Therefore we cannot produce markdown report similar to console output.
We can go for placehod.it to have a color block in front of messages. (See https://github.com/slgobinath/pycode-analyzer/issues/1 for an example)

[Razze]

Thanks. I will go with pylint.

How would you like to format the markdown report?
GitHub does not support text color. Therefore we cannot produce markdown report similar to console output.
We can go for placehod.it to have a color block in front of messages. (See https://github.com/slgobinath/pycode-analyzer/issues/1 for an example)

 I would order by type and just bulletpoint them, not much different from what we currently do. Important thing is, that we have "must fixes" and "nice to have fixes". Not too worried about color.
And we might have to overthink that markdown support, as this weekend turned out, that we likely can't use that on github like we want.
See: https://github.com/xbmc/addon-check/pull...-372113092 for context

[gobinath]

With that PR, do we really need markdown report?

[Razze]

With that PR, do we really need markdown report?

 No, we don't the important part is not the markdown. The important part is to give clean and easy to read feedback for contributors.

[gobinath]

Hi,
According to the discussions so far, the following will be my deliverables:

• Static code analyzer for Python 3 using Python API (as in prototype)
  • By default ignore style issues but let users to enable them using test-config.json
    
  • Read configuration from .test-config.json. Do we need to support command-line arguments?
    
• Static code analyzer for Python 2 (by executing pyline as an external command using Python 2)
  
• Create setup.py and other files required to upload to pypi
  

Is there anything else to include?

[gobinath]

Please note that I am adding command line interface to my proposal which I will implement depending on available time.
We can create nice command line interface using argparse module available in Python. For a sample code, please have a look at my open source project Safe Eyes.main.py#L97.

[gobinath]

Hi,
I have shared my draft proposal though GSoC dashboard.
I would highly appreciate it if you could share your feedback on my draft to improve it further and to include any missing points.

Thanks

[gobinath]

Hi,
I received a comment for my draft porposal that the work is not enough for 3 months. I agree with that and I can go beyond pylint check.
What do you think about the following features?
1. Python code validation using pylint for errors and warnings
2. Cleaner command line interface (Issue #40)
3. Option to export found issues using Checkstyle (Issue #46)
4. Verify addon.xml against a xml schema (Issue #33)
5. Structure the project architecture to more extensible design

Do you have any other requirements to include?

Thanks