Comments in Python

Want to understand comments in Python? Comments are notes for humans, not for the interpreter. Python ignores them — so you can explain why code exists without changing what it does.

This page covers # line comments, end-of-line notes, what makes a comment useful, how good variable names reduce comment noise, multiline # blocks, and how triple-quoted strings differ from real comments. Pair it with Variables in Python — clear names and clear comments work together.

What you will learn

By the end you can:

• Write single-line comments with #
• Place comments on their own line or at the end of a statement
• Prefer comments that add why / context, not a restatement of the code
• Balance comments with good variable names
• Write multiline notes with stacked # lines
• Tell real comments apart from triple-quoted docstrings

We are not covering full docstring conventions for modules and classes, or tooling like Sphinx. This page is the beginner habit: leave useful notes for humans.

What are comments?

As programs grow, something changes. At first every line feels obvious. Later you return to your own code and it feels like a stranger wrote it. That is where comments earn their keep.

Comments are notes written for humans. They help explain:

• What a tricky section is doing (when the code is not self-explanatory)
• Why it is doing it that way — intent, units, constraints, tradeoffs

In Python, a comment starts with #. Everything from # to the end of that line is ignored:

# compute the percentage of the hour that has elapsed
percentage = (minute * 100) / 60

Python still runs the assignment. It simply skips the note.

Two ways to write comments

1. On a separate line

# calculate percentage of time passed
percentage = (minute * 100) / 60

2. At the end of a line

percentage = (minute * 100) / 60  # percentage of an hour

Everything after # on that line is ignored. Prefer end-of-line comments when the note is short; prefer a line above when the explanation needs more room.

What makes a comment useful?

A beginner instinct is to describe what the code already says. That is usually noise.

Bad comment — restates the obvious:

v = 5  # assign 5 to v

The code already says that. A good comment adds new information — context a reader would not get from the syntax alone:

v = 5  # velocity in meters/second

Now the comment earns its place: units and meaning. Prefer explaining why (or what a short name stands for) over narrating what.

Comments vs good variable names

Sometimes you do not need a comment at all:

velocity = 5

The name already carries the meaning. Better naming reduces the need for comments — which is why this page sits next to variables in the learning path.

There is still a tradeoff:

• Very long names can make expressions hard to read
• Very short names may need a brief comment for units or context

Balance clear names + meaningful comments — not walls of notes, and not cryptic one-letter soup.

Multiline comments

Sometimes one line is not enough — complex logic, a block’s purpose, or a short design note. Python has no special multiline comment symbol. The usual approaches:

1. Multiple # lines (recommended)

# This program calculates percentage
# of time passed in an hour
# based on the given minute value
percentage = (minute * 100) / 60

Stacked # lines are the standard, recommended way to write longer comments.

2. Triple quotes (docstring-style)

"""
This program calculates the percentage
of an hour that has elapsed.
Used for explanation of logic.
"""
percentage = (minute * 100) / 60

Those triple quotes create a string, not a true comment. When the string sits alone as a statement, Python creates it and then discards it — so it behaves a bit like a comment, but it is still a string object. The proper home for """...""" is documentation strings (docstrings) on modules, functions, and classes.

Common mistakes

• Commenting every line with a restatement of the syntax
• Leaving comments that contradict the code after a refactor
• Using triple quotes as a substitute for # everywhere
• Skipping comments where units, edge cases, or intent are non-obvious
• Relying on comments to fix unclear names instead of renaming

Final insight

Code tells Python what to do. Comments tell humans why it is done. In real programming, writing for humans matters as much as writing for machines.