Introduction to Idioms in Python


Intro to Idioms in Python

The course is part of this learning path

Python: Introduction to Idioms

In this course, we'll look at rules for writing Python code, PEP 8, and various naming conventions. This course is part of a series of content designed to help you learn to program with the Python programming language.

Learning Objectives

  • Describe the concept of Pythonic code
  • Describe the purpose of PEP 8
  • Describe the naming convention for common types

Intended Audience

This course was designed for first-time developers wanting to learn Python. 


This is an introductory course and doesn’t require any prior programming knowledge.


Hello, and welcome! My name is Ben Lambert, and I’ll be your instructor for this course. This course is part of a series of content designed to help you learn to program with the Python programming language. Should you wish to ask me a specific question, you can do that with the contact details on screen. You can also reach support by using the email address: And one of our cloud experts will reply. 

When writing Python code there are rules that we have to follow in order for our code to be considered valid by the interpreter. Our code has to conform to Python’s language syntax. Often, when these rules aren’t followed the interpreter will raise an error. Once we fix the code, the error goes away. These rules are enforced by the Python interpreter. Our code either passes the rules or it doesn’t.

When programming we’re constrained by these types of rules. However, there are some other rules that we have to consider when writing code. Rules that determine the style of our Python code. These stylistic rules will be our topic for this lesson. What exactly does it mean for code to have style? The style of code is all about consistency. When code follows some consistent rules it tends to make that code easier to read.

As developers, we have control of the names of objects and object types in our code. We can control which whitespace characters to use for Python’s indentation. We can control the creation and use of comments. And many other aspects which don’t have any enforceable rules. The concept of style is important to Python. Python is one the world's most commonly used programming languages. Imagine if all Python developers followed their own code style. It would make it more difficult to read other developer’s code if their style was quite different from ours.

Allow me to introduce the concept of Pythonic programming. Code is said to be Pythonic when it follows the current community recommended styles. Early on in Python’s history, a Python style guide was created by the community. This guide is known as PEP 8. This guide defines a set of styling rules that when followed will ensure that the code we write looks like the Python code created by other Python developers.

Let’s review a few of PEP 8’s recommendations. PEP 8 recommends that we use 4 spaces to represent a single indentation level. This is something I highly recommend that you follow in your code! This standard is so common that it’s the default in just about every text editor with Python syntax awareness. 

PEP 8 recommends that we don’t include extra white space around name-bindings and some of the different symbols that they touch. PEP 8 also defines how we should name objects and types. Python’s syntax includes rules for which characters are allowed for different types of names. For example a name binding can’t start with a number. It’s just one of Python’s rules. Across the entire tech world there are a lot of potential naming conventions. Here are some common naming conventions used across different  programming languages.

This list is taken directly from PEP 8. If you spend long enough working with Python, you’ll probably see all of these used at some point. However, Python only recommends that we use a few of these in our Python code. PEP 8 recommends that callables be named using lowercase words or lowercase with underscores if we need multiple words to describe the purpose of the callable. PEP 8 recommends that classes be named using CapitalizedWords. This makes it easier to know at a glance if something is a callable or class.

PEP 8 makes a recommendation regarding naming exceptions. If the exception represents an error then we include the word Error at the end of the class name. Exceptions in Python indicate that the expected code flow has been disrupted. So not all exceptions are errors. However some are. For example the FileNotFoundError. PEP 8 makes a lot of recommendations. And if we follow them all for the most part, our code should be more readable for it.

However, it’s important to know when it’s worth following these recommendations and when it’s not. The entire reason for this style guide is to help make code more readable. However, some of these standards may make your code less readable. Knowing when to ignore a rule is important. Here’s an example. One of PEP 8’s recommendations is that the maximum number of characters on a single line should be 80. This recommendation might have had a lot of value back when terminals only displayed a limited number of characters.

However, it’s less important these days. In this example line is 83 characters long. To try and break this into multiple lines just because PEP 8 recommends 80 character lines would be silly. Because breaking this code onto two lines makes the code less clear. If breaking a line of code onto another line makes the code more readable - then it’s worth doing. In this example the function call is over 100 characters long. 

Breaking this code onto multiple lines doesn’t make the code any less readable. Though, it might make it more readable. Code is read more often than it’s written. When we adhere to the style guide recommendations of PEP 8 we can ensure that our code is readable to other Python developers. The purpose of code is to solve some problem. The code we create is our set of instructions for how to solve a given problem. These instructions are not just for the interpreter, they’re for all future developers who will read this code. 

Following the same standards that much of the Python community follows is going to help you learn to write better Python code; and more quickly extract the intent of code when reading Python. Before wrapping up this lesson, I want to share a sort-of Python easter egg. To get a better insight into the minds of Python developers, type import this from inside an interactive Python console. This will display the Zen of Python. Give it a read and then think about Python again through this new lens. This new lens that favors simplicity over more complicated options.

I recommend reading through this guide. You may not understand all of the concepts covered just yet. Though, it’ll help you to grow your intuition for what would be considered Pythonic code. Okay, this seems like a natural stopping point. Here are your key takeaways for this lesson:

  • The concept of Pythonic code refers to code that follows the Python community’s current code styles.

  • The purpose of PEP 8 is to serve as the default community style guide

  • PEP 8 includes naming convention recommendations for:

    • Callables - which use lowercase and lowercase with underscores.

    • Classes - which use CapitalizedWords

    • Exceptions - if the exception represents an error use the suffix Error. 

  • Know when to ignore the recommendations.

Alright, that's all for this lesson. Thanks so much for watching. And I’ll see you in another lesson!

About the Author
Learning Paths

Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.

Covered Topics