10 Acronyms That Every Python Programmer Should Know

New to Python? 10 Acronyms That Every Python Programmer Should Know

Programming principles, rules, and some fun facts

Yong Cui, Ph.D.

Follow

Jul 27 ·9min read

Introduction

Python has become the choice of programming language for many people who start to learn coding. It has very intuitive syntax and flexibility of supporting dynamic typing. In addition, it’s an interpreted language, which makes it possible to use an interactive console for learning purposes. Basically, you can just use a command-line tool, such as Terminal in Mac, to start Python learning, because macOS is nowadays shipped with Python.

When you learn Python, you’re gradually getting familiar with its data structures, control flows, classes, functions, and other basic stuff. One thing that I’ve found to be interesting is various acronyms in Python, which we encounter from time to time. This article is to review ten such acronyms. Some of them are general programming principles, while some others are more specific to Python coding. Nevertheless, each of them has its own useful and/or intriguing aspects.

1. OOP (Object-Oriented Programming)

The first acronym that we should know is OOP — Object-Oriented Programming, and this is what Python is designed based on. We know that programming itself is about coding, but programs themselves should be about data. Our programs need to take input data, process data, and output data. Please be noted that data that are discussed here are in the most general sense, which can include tabular data, strings, user actions (e.g., button clicking), images, and any form of data that has information. Our code’s job is to handle these various forms of data and present them in the desired way.

To accomplish our job, we need to our code that is capable of processing these data, and one common design pattern in modern programming languages, including Python is to take the OOP paradigm. The idea is very intuitive — we wrap our data with particular objects. More specifically, the objects can hold data (e.g., attributes) and can operate data (e.g., methods). For instance, if we build a car racing game. We can build car objects, and each of them can have particular attributes, such as color, max speed, and weight. In addition, these objects can have operations, such as brake and accelerate. The logical organization of these data is centered at the object — the car.

Let’s look at a specific example in Python. We can wrap the string data using the built-in str class, which will not only allow us to pass string data using a string object, but allow us to change the way how the string is represented. Let’s see a very trivial example below.

2. DRY (Don’t Repeat Yourself)

The principle of DRY (Don’t repeat yourself) is one of the most fundamental rules that every programmer should practice. The idea is simple — if you notice there are any repetitions in your code, it’s a signal that you need to have some refactoring to minimize the repetitive code or remove any repetitions completely if all possible. The following pseudo-code shows you a refactoring of some code by applying the DRY principle.

Another possible scenario for code refactoring is that you find yourself to deal with a bunch of data that have the same structure. Instead of using a series of dictionaries, lists, or tuples to store each individual’s data, you should consider having your own class to deal with these data. It’s not only about making your code less prone to bugs, but also beneficial for long-term maintainability.

3. PIP (Package Installer for Python)

The probably most significant contributor to Python’s popularity is its open-source nature, which has engendered a huge collection of free Python packages. According to Wikipedia , there are over 235,000 packages that are indexed in the Python Package Index (PyPI). We can use the pip tool to install any packages from the PyPI. The installation is rather hassle-free, which requires just one line of code in your command or Terminal. Some common usages are summarized in the following code snippet. To learn more about the usages of the pip tool, you can visit its official website here .

4. LEGB (Local, Enclosing, Global and Built-in)

The LEGB rule refers to the variable look-up order in Python, as shown in the following diagram. Specifically, Python has four layers of scopes when the interpreter tries to resolve the variable — understand what values are bound to the variables. It’ll first start with the local scope , which can be a function or a class. If the interpreter finds the corresponding bound value for the variable, it’ll stop looking up and use the variable with that particular value.

Otherwise, it’ll look it up at a higher level — the enclosing scope . The enclosing scope only exists in a nested structure of functions. Specifically, when a function is declared within another function, we call the inside function the inner function and the outside function the outer function. When the interpreter tries to resolve the variable used within the scope of the inner function, if it can’t resolve in the local scope, it’ll go to the enclosing scope, which is the local scope of the outer function.

If it still can’t resolve the variable in the enclosing scope, it’ll go to the global scope . The global scope usually is the module level, which typically is a standalone Python file. Notably, when you import packages into the current file, the functions and classes from the import will also become part of the global scope. The built-in scope is the functions, classes, and other modules that are loaded when an interpreter is launched to make these most basic objects always available for use (e.g., the print and other built-in functions).

5. MRO (Method Resolution Order)

The Method Resolution Order denotes how Python or a programming language in general resolves a method or attribute . Unlike the LEGB rule discussed above, which is concerned about resolving a variable, the MRO is concerned about an object and how its calling of a method or retrieving a particular attribute is resolved. The MRO is mostly discussed in the context of multi-inheritance — classes (i.e., subclasses) inheriting from multiple classes (i.e., superclasses) and/or multi-layers of inheritance. Because both subclasses and superclasses share some common methods with possibly varied implementations, Python interpreter needs to have a mechanism to determine which method or attribute should be used in a particular call, and this is what the MRO takes the responsibility. A schematic example is shown in the code snippet below.

For the instance of the W class (Line 22), when we call the bingo() method, this method is resolved at its own class, because it’s defined in the class (Lines 18–20). However, this method will further call both bin() and go() methods. In a similar fashion, the bin() method gets resolved at its own class, however, it’s calling the superclass’s bin() method, as shown in Line 15. But in its immediate superclasses (i.e., Y and Z), neither implements the bin() method and thus Python will go even one level higher to the superclasses’ superclass (i.e., X), where the bin() method is implemented and called.

Notably, for W’s go() method, both its superclasses implement this method, but as you can see, only the implementation used in the Y class gets called. It’s because when we define our W class, the inheritance order is Y and Z, which will make the MRO follow the same order. Relevant to this, we can find out the MRO of a particular class using the special method __mro__ , as shown below. In addition, to show you how the order of class inheritance matters, we create another class with the Z class preceding the Y class, which changes the MRO of the W_ class.

6. & 7. EAFP (Easier to Ask Forgiveness than Permission) & LBYL (Look Before Your Leap)

The EAFP (Easier to Ask Forgiveness than Permission) coding style is what Python thrives to follow. Because Python is a dynamic programming language, implementations as well as modifications to exiting instance objects, classes, and even modules are all possible during runtime. Thus, it’s recommended that you write your code assuming particular attributes or functionalities are available. In other words, the idea is that if some code potentially has particular problems, let the problems surface and solve them accordingly. By applying the EAFP rule, if we want to take a step further, we can simply write particular code using the try…except statement to handle potential exceptions that the code may raise. Basically, the idea is that something unexpected happens and we handle them post-hoc.

Contrary to the EAFP principle, there is another coding style termed LBYL, which stands for Look Before You Leap. With this coding style, programmers are expected to rule out all possible undesired conditions before certain code can run. Thus, you can see many more if statements in projects that follow more to the LBYL principle. Basically, this coding style is trying to prevent any problems in an ad-hoc fashion.

The following code snippet shows you a possible scenario using EAFP vs. LBYL. With the EAFP coding style, we simply wrap our code and expected possible exceptions in a try…except statement, while with the LBYL coding style, we have to use introspection methods and value checking to verify the applicable conditions before the division. As you can see, the EAFP code looks cleaner without creating a nested structure. Certainly, if you prefer, you can also apply LBYL in your projects. The end project will still work similarly.

8. PEP (Python Enhancement Proposals)

The previous section discussed the coding style in general. But one of the most influential Python coding style guidelines is known as the PEP 8 — the Python Enhancement Proposal # 8, authored by the BDFL (which will be discussed next) and a couple of other Python core maintainers. The PEPs cover lots of things — all Python related. You can find the whole list at the official website . Some notable ones are listed here, and please feel free to read them.

PEP 8: Style Guide for Python Code

PEP 257: Docstring Conventions

PEP 20: The Zen of Python

PEP 498: Literal String Interpolation

PEP 202: List Comprehensions

PEP 405: Python Virtual Environment

9. BDFL (Benevolent Dictator For Life)

What’s the BDFL? Certainly, the section title has told you what it stands for, but what does it mean actually? Here’s the definition from Wikipedia .

Benevolent dictator for life( BDFL ) is a title given to a small number of open-source software development leaders, typically project founders who retain the final say in disputes or arguments within the community.

Although this definition applies to open-source software development in general, it was first used in the Python community, as a way to refer to Guido van Rossum (GvR), who is the creator of Python programming language. After serving this BDFL role for over 20 years, he stepped down his role in 2018. If you’re interested in the story about the BDFL, please feel free to explore more on his Wikipedia page.

10. REPL (Read-Eval-Print Loop)

In my opinion, the REPL (Read-Eval-Print Loop) is a convenient tool to make learning Python so painless. As you know, we can start to learn Python coding as simple as using a command or terminal window. You can install your packages there as shown previously using the pip tool. More importantly, you can write your first line of Python code (e.g., probably should be this one: print(“Hello World!”) ) immediately without any configuration of IDE tools that you may need with other programming languages. Let’s take a quick snapshot of what it looks like.

The REPL workflow is very straightforward — read the code, evaluate it, and print any applicable result from the evaluation in the console, and you repeat these three steps again and again to explore various features of Python. The REPL is implemented as the default mode in the standard Python or other common Python development tools, such as ipython, which is the basis for the reputable Python learning and coding tool — Jupiter Notebook .

Conclusions

Python is a flexible yet powerful OOP language, which was created by the BDFL GvR. Utilizing the PIP, we can easily manage Python packages and learn the language and various packages in the console through REPL. When we code in Python, we want to follow the styles outlined in PEP 8. Other important coding principles include DRY and EAFP. If you prefer, you can also do some LBYL in your coding. The LEGB rule and MRO will help you understand how variables, attributes, and functions are resolved to make your code run as expected.