A linter is used to catch problems that are related to our usage of the language. For example if we forget to add a colon (:), or if we forget to import something we need. A linter will let us know of these things.
Installing and using a linter is very easy with Python3, just do:
pip install pylint
When you do this, you can run it in order to ensure your code is adhering to the default style.
To run it, just navigate using the terminal to the folder that contains your code, and run pylint:
pylint myfile.py
Pylint will then tell you any problems it has found in your file.
For example, for a file that looks like this:
Mailgun.send(['[email protected]'], 'Test e-mail', 'This is a test e-mail')
Pylint will say:
No config file found, using default configuration
************* Module using_mailgun_lib
C: 1, 0: Missing module docstring (missing-docstring)
E: 2, 0: Undefined variable 'Mailgun' (undefined-variable)
-----------------------------------------------------------------------
Your code has been rated at -50.00/10 (previous run: -40.00/10, -10.00)
That's some pretty bad code! It's got a score of -50 because it won't even run—since we've got an undefined variable.
If you add the things it says are missing:
"""
Sample code on how to use our new Mailgun library to
reduce code duplication.
This library sends an e-mail to '[email protected]', with
subject 'Test e-mail' and content 'This is a test e-mail'.
"""
from libs.mailgun import Mailgun
Mailgun.send(['[email protected]'], 'Test e-mail', 'This is a test e-mail')
Then it’s happy, and says:
No config file found, using default configuration
--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
Now, you may not always want to include module docstrings (I know I don't!), so it’s easy to disable that check:
pylint --disable=missing-docstring using_mailgun_lib.py
That disables the “checker” missing-docstring, which is the one that checks for docstrings in modules and functions.
You can run pylint for all files in a folder just by giving it the path to the folder, such as:
pylint my_module
Formatting our code
Normally we try to adhere to certain styles when we code. Style doesn’t necessarily cause problems with our code—which is what Pylint catches—but it can still be good to stick with a consistent style throughout a project.
For example, much of the Python community would prefer this code:
x = {'a': 37, 'b': 42, 'c': 927}
y = 'hello ' 'world'
z = 'hello ' + 'world'
a = 'hello {}'.format('world')
class foo(object):
def f(self):
return 37 * -+2
def g(self, x, y=42):
return y
def f(a):
return 37 + -+a[42 - x:y**3]
Over this code:
x = { 'a':37,'b':42,
'c':927}
y = 'hello ''world'
z = 'hello '+'world'
a = 'hello {}'.format('world')
class foo ( object ):
def f (self ):
return 37*-+2
def g(self, x,y=42):
return y
def f ( a ) :
return 37+-+a[42-x : y**3]
Granted, this is a bit of an exaggeration—I’d like to think none of you is writing code that looks like that—but nonetheless things like inconsistent spacing, newlines, quotation marks, and more can easily be made consistent using a formatter.
There are a few formatters for Python, but two of them come to mind:
yapf is a long-standing Python formatter which has been around for a long time; whereas Black is a new Python formatter that is gaining traction. Feel free to use either, but in this guide we'll stick to the long-standing one: yapf.
To install yapf, just do it via pip like we did for pylint:
pip install yapf
Then, you can run the formatter on a file by navigating using the terminal to the folder containin that file, and doing:
yapf myfile.py
That will show you what yapf would like to do—but it won't change your file and re-format it. If you want to change your file, you can do so like this:
yapf -i myfile.py
For more information, check out the official readme.
I hope this short post on Python development tools was helpful! I always recommend running a linter. It can also a good idea to run a formatter so that everyone working in a project will adhere to the same style. However, formatters can also make you a bit lazy and not care about the style of your code.
I always try to make everything nice myself, and then run the formatter anyway so that the project is consistent throughout.
