Python 101

Python is – as I have said before – a simple language to pick up. It is meant to be readable by the layperson and the logic of its code is meant to be easily understandable. It is because of this fact that everything from installing Python to configuring it in your OS is probably the smoothest installation process out of any of the major programming languages. The barrier of entry is next to zero.

So, if you want to declare a variable and other basic stuff, start from the following figure and figure it out:

Figure 2.1 – Declaring and manipulating variables

This section will be focused on the philosophy of Python because that is what will be important in your journey toward using Python in DevOps. Once you understand the underlying philosophies, you will understand why Python and DevOps are such a perfect match.

In fact, we can find that similarity in the Zen of Python. The Zen is a series of principles that have come to define the Python language and how its libraries are built. The Zen of Python was written in 1999 by Tim Peters for his Python mailing list. It has since been integrated into the Python interpreter itself. If you go to the command line of the interpreter and type in import this, you’ll see the 19 lines of Zen. Odd number, you say? It’s an interesting story.

So, if you haven’t seen it before, I’m going to list it out here for posterity:

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren’t special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one– and preferably only one –obvious way to do it.

Although that way may not be obvious at first unless you’re Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it’s a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea — let’s do more of those!

(Tim Peters, 1999, The Zen of Python, https://peps.python.org/pep-0020/#the-zen-of-python)

The reason I’m laying this out for you right now is so that I can give you examples of how these principles have become a part of the fully evolved Python language. I am going to do this in pairs. Except for that last one. These rules and their implementations will provide you with the appropriate boundaries that you need to write decent Python code.