79 characters

Inspired by Daniel Stenberg’s blog post¹, hereby I declare myself as a 79-character purist.

When I started using PyCharm for my personal, and work, projects one of the first things that I did was to learn about code formatting.

I was coming from a C# world where tabs are preferred over spaces, and back in the day there were no style guides for C# code.

Why style guides are certainly a good thing

I could summarize my comments with just one word: consistency.

Producing consistent code across multiple projects, and applying a style is a positive thing to do.

There are many articles out there about their importance, just search for coding style guide using your favorite search engine and you’ll find multiple writings. Bing it, DuckDuckGo it, Google it.

So I won’t repeat what many have said, instead I will share my preferences.

PEP8

PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment. The PEP should provide a concise technical specification of the feature and a rationale for the feature.²

From PEP 8 is where I decided to use 79 characters for code, and 72 characters for the docstring³.

But why 79?

One could trace back the “80 characters/columns per line” constraint to punched cards, something that is part of the history of computing that most of us have only seen in textbooks, documentaries, or museums.

Also, one could argue that with modern screens which come in bigger sizes and offer higher resolution, such a limit is nonsense. Trust me, I use a 55” 4K TV as a computer monitor, but I also use a 13” MacBook Air for working on the same projects, and if I were to “take full advantage” of the 3840x2160 resolution from the 4K TV, there would be a lot of horizontal scrolling on my 1440x900 from the MacBook Air; and horizontal scrolling is still undesirable on a PC.

Docstring formats

Within PyCharm (version 2020.3.1 at the time of this post) a couple of options for docstring formatting are offered. I’ll use the following function as an example for each.

def file_exists(filepath):
    import os.path
    return os.path.isfile(filepath)

Docstring will autogenerate as soon as you type three double-quotes """, and hit Enter.

Plain

def file_exists(filepath):
    """

    """
    import os.path
    return os.path.isfile(filepath)

Epytext

def file_exists(filepath):
    """

    @param filepath:
    @return:
    """
    import os.path
    return os.path.isfile(filepath)

reStructuredText (PyCharm’s default)

def file_exists(filepath):
    """

    :param filepath:
    :return:
    """
    import os.path
    return os.path.isfile(filepath)

Numpy

def file_exists(filepath):
    """

    Parameters
    ----------
    filepath

    Returns
    -------

    """
    import os.path
    return os.path.isfile(filepath)

Google

def file_exists(filepath):
    """

    Args:
        filepath:

    Returns:

    """
    import os.path
    return os.path.isfile(filepath)

My preference was the Google format^{4 5}.

Code formatters

Again, there are many options out there. There’s autopep8, Black, YAPF, and, surely, many more. Choosing one would be a matter of preference.

Since I still write Python 2.7 code, or rather Jython 2.7.1, at first I chose YAPF because it did what it was supposed to do; format my Python 2 code with a single command. But I’ve recently switched to Black. And the reason is very simple. Python 2 reached its end-of-life since 2020-01-01, and when you run pip2 you get the following warning:

$ python2 -m pip list
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop support for Python 2.7 in January 2021. More details about Python 2 support in pip can be found at https://pip.pypa.io/en/latest/development/release-process/#python-2-support pip 21.0 will remove support for this functionality.

And while YAPF (python2 -m pip install yapf) supports Python 2.7, it requires the code it formats to be valid Python for the version YAPF itself runs under. Therefore, if you format Python 3 code with YAPF, run YAPF itself under Python 3 (and similarly for Python 2)⁶.

The January 2021 date is the final nail in the coffin for Python 2.7, and since there is no way of formatting Python 2.7 code with YAPF running under Python 3, the only option I could find was Black.

Enter Black

Black can be installed by running pip install black. It requires Python 3.6.0+ to run but you can reformat Python 2 code with it, too⁷.

By default, Black allows 88 characters per line, but running black --line-length 79 --target-version py27 . formats the code in the style that I like, and makes the end-of-lfe problem go away. And who doesn’t like emojis?

$ black --line-length 79 --target-version py27 .
All done! ✨ 🍰 ✨
39 files left unchanged.

Conclusion

A wise man once said:

“It’s a matter of preference. But convenience and ease of use override preference.” - César Román (2020-12-22).

Thanks for reading.

References