Exploring Contradictions and Balance

00:00 The examples in the previous lesson benefited immediately from a single change, but that won’t be true for your entire codebase. Some decisions are much more nuanced and require balancing a few different factors.

00:11 In this lesson, you’ll see some extracts from the Zen of Python, which will help you develop this sense of balance. Upon looking at the following phrase, “Simple is better than complex, complex is better than complicated”, you might wonder what the difference is between complex and complicated. One way to look at it is that a complex system is one made up of many interconnected parts, and a complicated system is one that is difficult to understand.

00:36 The poem is telling us that even large programs can be improved by being broken down into individually understandable building blocks, which could be functions or even self-contained programs that all talk to each other.

00:49 An example of this can be seen in this diagram of a banking program that lets a user withdraw or deposit money. The process is started by a user making a request to a banking API, which then authenticates the user from the user database.

01:04 Then the program updates the user’s bank balance using the bank account database before returning a response. The diagram shows how the program can be broken down into individual parts, which all handle different things so that no one part is complicated.

01:19 And as a whole, the program is understandable.

01:22 Drawing diagrams like these can help you plan your code before you write it. “Special cases aren’t special enough to break the rules, although practicality beats purity.”

01:35 Practicality is the key word here. This quote is suggesting that you should do your best to follow any guidelines or rules that have been published. A good example being PEP 8, which is a style guide for writing Python code covering all sorts of things like formatting your code, naming variables and functions, and how to write good comments.

01:54 That said, there may be a practical reason why you can’t follow the guidelines. For example, PEP 8 itself says, “do not break backwards compatibility just to comply with this PEP”. “Errors should never pass silently unless explicitly silenced.” As a general rule, you and your users probably want to know when an error has occurred, so they shouldn’t be hidden.

02:16 You can and should handle errors using try-except blocks to make robust programs. However, there are a few occasions where you can silence errors.

02:26 For example, when deleting a file, the os.remove() function will raise an error if it can’t find the file to delete. But that’s not a problem if all you want to do is make sure the file is gone, so you can let the error pass silently.

02:40 “Now is better than never, although never is often better than right now.” These lines are in reference to something called *premature optimization*, which is when developers focus on unnecessary efficiencies and optimizations before implementing useful features.

02:56 Instead, Python is great for iterative development, which is a process of rapidly adding features, testing them, and making incremental improvements.

03:05 On the other hand, you do need to prioritize what you’re adding to your program. You may be desperate to integrate the latest awesome library you just discovered, but there may be more pressing things to work on.

03:18 So now you can see that these seemingly contradictory phrases can help us find compromises and focus on practicality. The Zen of Python isn’t all practical though, there are a few jokes thrown in for good measure, which we’ll discover in the next lesson.