Introduction

Python has single-line comments with #, but it does not have a dedicated block-comment syntax like /* ... */. That choice is deliberate and fits Python’s general preference for a small, readable syntax rather than many overlapping language features.

Python Uses One Comment Syntax on Purpose

In Python, a comment starts with # and continues to the end of the line:

# Read configuration from disk
config = load_config()

If you need several lines, you repeat the marker:

1# This function reads the file,
2# validates the schema,
3# and returns normalized data.
4data = parse_file(path)

That may look repetitive if you come from C, Java, or JavaScript, but it keeps the grammar simple. Python does not need a second comment form, and the parser does not have to treat long spans of source code as a special nested structure.

Why Triple-Quoted Strings Are Not Real Comments

New Python developers often see this pattern:

"""
This looks like a multiline comment.
"""

It works sometimes, but technically it is a string literal, not a comment. If that string is the first statement in a module, class, or function, Python stores it as a docstring:

def area(radius):
    """Return the area of a circle."""
    return 3.14159 * radius * radius

If the triple-quoted string appears elsewhere and is not assigned, Python still parses it as an expression statement and then discards the result:

1def debug_mode():
2    """
3    Temporary note for developers.
4    """
5    return True

That means it can affect formatting tools, linters, and bytecode generation differently than a real comment. It is better to think of triple-quoted strings as multiline strings that can sometimes be ignored, not as Python’s hidden block-comment feature.

The Design Tradeoff

Python’s philosophy values one obvious way to do a thing. A dedicated multiline comment syntax would add another construct without solving a major problem, because repeated # already covers documentation and temporary annotations.

It also avoids confusion around nesting. In languages with block comments, the parser has to decide how nested markers behave:

/* outer
   /* inner */
*/

Python sidesteps that entire class of ambiguity by not having the feature.

The result is consistent:

• '# is for comments.'
• Triple-quoted strings are for strings and docstrings.
• Documentation tools read docstrings, not comments.

Practical Alternatives

For Explanations, Use Comments

If you want to explain implementation details, use normal comments:

1def normalize_name(value):
2    # Strip leading and trailing whitespace first so later checks
3    # do not treat formatting noise as meaningful data.
4    value = value.strip()
5    return value.lower()

For API Documentation, Use Docstrings

If you want help text that tools can inspect, use docstrings:

def normalize_name(value):
    """Return a lowercase, trimmed version of a user-supplied name."""
    return value.strip().lower()

Then you can inspect it interactively:

print(normalize_name.__doc__)

For Temporarily Disabling Code, Use Your Editor or if False

Commenting out many lines by hand is awkward in any language. In Python, editors solve most of that problem with a toggle-comment shortcut. For quick experiments, an if False: block is often clearer than wrapping code in a string:

if False:
    print("old debugging code")
    print("more temporary output")

That still parses as Python code, so syntax errors inside the block are visible immediately.

Common Pitfalls

The biggest mistake is treating triple-quoted strings as harmless comments everywhere. They can become docstrings, appear in generated documentation, or simply create unused string literals that confuse readers.

Another problem is using large comment blocks instead of extracting clearer code. If a function needs fifteen lines of explanation, the code structure may be the real issue. Smaller functions and better names usually beat heavier commenting.

Developers also sometimes use multiline strings to disable code and forget that the disabled block is no longer parsed as executable Python. That can hide syntax issues until the code is restored.

Finally, comments should not duplicate the code line by line. This is weak:

# Increment i by 1
i += 1

Comments are most useful when they explain intent, constraints, or non-obvious tradeoffs.

Summary

• Python intentionally has one comment syntax: #.
• Triple-quoted strings are strings, not true multiline comments.
• Use docstrings for public documentation and # comments for explanations.
• For temporarily disabling blocks, prefer editor shortcuts or if False: during experiments.
• The lack of block comments keeps Python’s syntax smaller and easier to read.