The weak typed languages, such as Ruby and Python, give you a lot of freedom by not enforcing you to explicitly declare variable names and their types. The good part is that you stay focused at the problem at hand by using the variable when you want rather than going into the fine details of the language. When you want to use a variable, just use it rather than going up in your code declaring the variable and coming back and re-thinking where you were in terms of the algorithm.
The downside of weak typing is that you can easily shoot yourself in the foot. Since everything is evaluated at run-time, your program will run smoothly until the problematic part of the code is executed. On the other hand, static typed languages such as C/C++ and Java prevent you from shooting yourself by enforcing you to specify the names of the variables you are going to use in a particular scope and their types. The compiler makes sure you haven't incorrectly used a variable and won't compile your program until you have fixed all of your errors. It can also warn you about the potential problems.
For instance, you use a variable named "colour" and few lines down you refer it as "color"; C++ or Java's compilers will catch it before the program is compiled and run. But if you run such Python code right away, you won't be that lucky. And if that piece of code is likely going to be run in a rare scenario, the problem might appear only at the production level.
However, using a code analyzer it is possible to detect many of the problems in weak typed languages without actually executing the code. The code analyzers can detect incorrect variable names, potential incorrect typing, warnings and coding style relating problems.
For Python, my choice of code analysis is PyLint. It is a simple and easy to use tool which quickly efficiently performs code analysis, finds bad smells in your code and can format the output neatly into a form of your choice. It also integrates well with different IDEs.
You can run PyLint by calling the lint.py script which is usually placed in the Python's site-packages directory.
It is a good idea to make a batch file and pylint.bat file to avoid typing all of that.
You can also specify command line parameters to pylint to control the output format and verbosity. There are numerous parameters but you'll probably need a few of them: the format option (-f) and Errors Only mode (-E).
The -f specifies the format options. Choices are text, parseable, msvs and html. Depending upon the choice of -f parameter, pylint outputs its results on stdout in the specified format. Parseable format can be used by IDEs to format the lines and integrate it with their editor so that you may click on a message and the IDE will take you to the corresponding line. HTML is useful in case of version control systems which display their outputs in browsers. For instance you can configure your SVN to run PyLint on each commit and output will be displayed in a browser.
Add -E in options to change mode to errors-only. This is effectively the verbosity level of PyLint and will report only the errors, skipping the coding style problems and other warnings.
Integration with PyScripter
Integration with PyScripter IDE is pretty simple. Just install PyLint and run PyScripter. Press CTRL + L and output of pylint for your code will appear in the list in the messages window pane. Clicking on a message from the list will take you to the correponding line in the editor
To see only the error messages and hide coding style and other related warnings, goto Tools -> Configure Tools -> Py&lint and append -E in Parameters. Now when you'll run Pylint, you'll only see errors.
Pylint is an extremely useful tool. It should be regularly used especially before committing your code to make sure you don't miss out anything. However one shouldn't completely rely on it as all code analyzers have their limitations.