Lint Python code for syntax errors

[cclauss]

Demonstrating why we need #3 or similar. Five files with Python syntax errors.

Output: https://github.com/cclauss/sobot-rimulator/actions

flake8 testing of https://github.com/nmccrea/sobot-rimulator on Python 3.8.3

$ flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics

./models/supervisor_state_machine.py:180:11: E999 SyntaxError: invalid syntax
    print "\n ======== \n"
          ^
./models/controllers/gtg_and_ao_controller.py:106:11: E999 SyntaxError: invalid syntax
    print "\n\n"
          ^
./models/controllers/go_to_goal_controller.py:92:11: E999 SyntaxError: invalid syntax
    print "\n\n"
          ^
./models/controllers/follow_wall_controller.py:182:11: E999 SyntaxError: invalid syntax
    print "\n\n"
          ^
./models/controllers/avoid_obstacles_controller.py:114:11: E999 SyntaxError: invalid syntax
    print "\n\n"
          ^
5     E999 SyntaxError: invalid syntax
5

https://flake8.pycqa.org/en/latest/user/error-codes.html

On the flake8 test selection, this PR does not focus on "style violations" (the majority of flake8 error codes that psf/black can autocorrect). Instead these tests are focus on runtime safety and correctness:

• E9 tests are about Python syntax errors usually raised because flake8 can not build an Abstract Syntax Tree (AST). Often these issues are a sign of unused code or code that has not been ported to Python 3. These would be compile-time errors in a compiled language but in a dynamic language like Python they result in the script halting/crashing on the user.
• F63 tests are usually about the confusion between identity and equality in Python. Use ==/!= to compare str, bytes, and int literals is the classic case. These are areas where a == b is True but a is b is False (or vice versa). Python >= 3.8 will raise SyntaxWarnings on these instances.
• F7 tests logic errors and syntax errors in type hints
• F82 tests are almost always undefined names which are usually a sign of a typo, missing imports, or code that has not been ported to Python 3. These also would be compile-time errors in a compiled language but in Python a NameError is raised which will halt/crash the script on the user.

[nmccrea]

@cclauss thanks so much for this. This project has been in suspended animation for some time but I will be getting things moving again in short order.

[nmccrea]

@cclauss Thank you very much for this. I have now linted this entire project with black, codespell, and flake8. I made some modifications to the Github action you created here but the spirit remains the same.

Among other things I have made the action fail if any of these three tools find problems. At the moment, these checks still do not pass. This is because there are a handful of remaining problems found by black and flake8. They fall into two categories:

• module imports - The use of GTK and the associated gi library requires some funky import behavior. I am hoping to migrate this project away from GTK at some point soon so that should solve these problems.
• line length - Most remaining line length errors can be resolved by cleaning up the code and implementation - editing comments, shortening names, and realizing readability improvements that come with better separation of concerns.

My hope is that we can get these remaining problems cleaned up before long and then begin enforcing this action for all PRs.