Python Pass Statement | pass Keyword Explained | Python Tutorial for Beginners 2026

What is the pass Statement in Python?

Python doesn't use curly braces to mark code blocks. It uses indentation, which is exactly why the language reads so cleanly — and exactly why it panics the moment a block is empty. Write an if, a for loop, a function, or a class with nothing inside it, and Python refuses to run. It needs at least one statement in that block. pass is that statement — a keyword whose entire job is to do absolutely nothing while still counting as valid code.

That sentence — "a keyword that does nothing" — sounds like a joke the first time you hear it, but it's the literal, accurate description. pass is a null operation. When the interpreter reaches it, nothing happens. No value is returned, no variable is touched, no side effect occurs. Execution just moves to the next line. And that's precisely the point.

I remember the first time this actually mattered to me, not as a syntax curiosity but as a real workflow tool. I was sketching out a class with six methods before writing any of their logic — just to get the interface right and let a teammate start writing calling code against it. Every method body was pass. It let the whole file parse, import cleanly, and be usable as a stub while the actual logic got filled in over the next two days. Without pass, that file wouldn't even import — Python would throw a syntax error before a single test could run.

This guide covers exactly when Python demands pass, why a comment alone doesn't satisfy that demand, how pass differs from continue, break, and the ... Ellipsis object, and the specific error message you'll see the moment you forget it.

History — Why Python Needed a No-Op Keyword

pass isn't a recent addition or a stylistic choice bolted on later — it's baked into Python's design from the very first releases, a direct consequence of the decision to use indentation instead of braces.

▶
1991 — Python 0.9.0 — pass was present from the earliest public release of Python. Guido van Rossum's decision to enforce significant whitespace over C-style braces meant an empty block had no closing } to fall back on — the language needed an explicit placeholder token, and pass filled that role from day one.
▶
Comparison with C-family languages — In C, Java, or JavaScript, an empty block is simply {} — two characters, no keyword required, because the braces themselves define the block boundaries regardless of what's inside. Python has no such punctuation to lean on; indentation alone can't signal 'this block intentionally has nothing in it' without something occupying that indented line.
▶
1994 — Python 1.0 — pass carried forward unchanged as one of Python's reserved keywords, alongside the other early control-flow words like if, for, and while. It has never been deprecated, modified, or given alternate syntax in any Python release since.
▶
2008 — Python 3.0 — Despite the sweeping backward-incompatible changes of Python 3.0 — print becoming a function, integer division changing, strings going full Unicode — pass was untouched. It's one of the few pieces of Python syntax with zero behavioural difference between Python 2 and Python 3.
▶
2015 — PEP 484 and stub files (.pyi) — Type hinting introduced .pyi stub files, where entire function signatures exist with no implementation, purely to describe types for static analysis tools like mypy. pass became the standard filler for these stub bodies, cementing its role as the 'this is intentionally incomplete' signal across the ecosystem, not just inside .py files.
▶
2026 — still exactly the same — Nothing about pass has changed, and nothing needs to. It's one of the most stable, unglamorous corners of the language — which is exactly why it rarely gets its own tutorial, even though nearly every beginner runs into the error it prevents within their first week.

Key Characteristics of the pass Statement

pass looks trivial, but it has a precise, narrow job description. Here are the 9 things worth knowing exactly, not vaguely:

🚫

Does Literally Nothing

pass is a null operation. No computation, no side effect, no return value. It exists purely to satisfy Python's syntax requirement that every indented block contain at least one statement.

🧱

Syntactic Placeholder

Wherever Python's grammar demands a statement — inside if, for, while, def, class, try, with — pass can legally occupy that spot when there's genuinely nothing to execute yet.

🗨️

Not the Same as a Comment

A comment (# like this) is invisible to the parser entirely — it's stripped before execution even begins. pass is an actual statement the interpreter processes. A block containing only a comment is still an empty block and still raises IndentationError.

⚡

Zero Runtime Cost

pass compiles to a single, extremely cheap bytecode instruction. Executing it a million times in a tight loop has no meaningful performance impact — it is about as close to free as code gets.

🔑

A Reserved Keyword

pass is one of Python's reserved words — you cannot use it as a variable, function, or class name. Trying pass = 5 raises SyntaxError: cannot assign to keyword.

🏗️

Common in Stub Code

When designing class interfaces or planning function signatures before writing logic, pass lets the skeleton run, import, and be tested for structure — even though none of the real behaviour exists yet.

🔀

Works Inside Any Block Type

if, elif, else, for, while, def, class, try, except, finally, with — pass is valid inside every one of these when the block would otherwise be empty.

🧩

Different from continue and break

pass does nothing and lets execution fall through normally to the next line after the block. continue skips to the next loop iteration. break exits the loop entirely. Confusing these three is a genuinely common beginner mistake.

📝

Often Temporary by Design

pass frequently marks 'not implemented yet' — a deliberate placeholder meant to be replaced. Leaving pass in production code for a function that should have real logic is usually a sign something got forgotten, not a sign of good design.

How pass Behaves at Runtime — Flowchart

The confusion between pass, continue, and break almost always comes from not tracing exactly where control flow goes after each one executes inside a loop. The flowchart below traces all three side by side inside the same for loop, so the difference in wiring is visible rather than just described in words.

🔁 for item in list:Loop starts, next item fetched

checking

❓ Condition Checkif item meets some rule

if using pass

⏭️ pass EncounteredDoes nothing at all

nothing happened

➡️ Falls ThroughExecutes rest of loop body normally

loop continues normally

⏩ continue EncounteredSkips remaining loop body

rest of body skipped

🔄 Back to Loop StartFetches next item immediately

next iteration

🛑 break EncounteredAbandons the loop entirely

loop terminated

🚪 Exit LoopCode after the loop runs next

Code Execution Flow — from source to output

Key insight: pass doesn't interrupt anything — it's the only one of the three that lets the rest of the loop body keep executing after it, exactly as if it weren't there at all. continue and break both change control flow; pass is the one option that changes nothing whatsoever.

How pass Actually Works — Empty Blocks, Stubs, and the Errors It Prevents

The cleanest way to understand pass is to first understand exactly what breaks without it, and then look at the three most common places it shows up in real code.

⚠️ The Error pass Exists to Prevent

Try writing an if block with nothing inside it: if user_logged_in: followed by nothing but a blank line or the next unindented statement. Python raises IndentationError: expected an indented block after 'if' statement. This isn't Python being fussy — the parser genuinely cannot proceed, because it has no idea what you meant to happen when the condition is true. There's no default 'do nothing' behaviour it can silently assume. You have to tell it, explicitly, and pass is that explicit telling.

🏗️ Stub Functions and Classes During Planning

This is the single most common real-world use. When sketching out an API before implementing it — say, a PaymentProcessor class with methods charge(), refund(), and validate_card() — writing all three method signatures with pass as the body lets the whole module import successfully. A teammate, or your own test file, can immediately start writing code that calls these methods and structurally checks the interface, even though calling charge() right now does nothing and returns None. This is functionally identical to what other languages solve with abstract methods or interface declarations — Python just does it with the same keyword you'd use for any empty block.

🔍 Filtering Loops Where Most Cases Need No Action

In a loop with several elif branches, sometimes most cases genuinely require zero action and only one or two need real logic. Rather than writing a suspicious-looking one-line comment as a stand-in, pass communicates clearly: 'this branch was considered and deliberately does nothing,' which reads very differently from a branch that was simply forgotten.

🧪 Placeholder except Blocks (Use With Real Caution)

You'll sometimes see except Exception: pass — swallowing an error and doing nothing about it. This pattern has a bad reputation for good reason: it silently hides bugs that should probably crash loudly during development. There are legitimate narrow cases — cleanup code where a failure genuinely doesn't matter — but as a general habit, bare except-pass blocks are how production systems end up failing silently for weeks before anyone notices. If you catch it, at minimum log it.

Simple rule to remember: pass is for 'nothing happens here, and that's intentional and correct.' If you're using pass because you genuinely haven't written the logic yet, that's fine during development — just don't let it silently survive into a merged pull request.

pass vs continue vs break vs Ellipsis (...) — Key Differences

Beginners frequently reach for the wrong one of these four, especially inside loops. This table lines them up directly.

Feature	pass	continue	break	... (Ellipsis)
What it does	Nothing — a true no-op	Skips to next loop iteration	Exits the loop entirely	A literal object, valid anywhere an expression is
Valid outside loops?	✅ Yes — if, def, class, etc.	❌ Loops only	❌ Loops only (also switch-like match/case)	✅ Yes — anywhere an expression works
Effect on control flow	None whatsoever	Jumps back to loop condition	Jumps past the entire loop	None — it's just a value, like None
Common use case	Empty block placeholder / stub	Skip invalid items mid-loop	Stop searching once found	Type stub files, placeholder in slicing
Runtime cost	Effectively zero	Effectively zero	Effectively zero	Effectively zero
Readability signal	'Intentionally does nothing'	'Skip this one, keep going'	'Stop right now'	'Not implemented / to be filled in'
Typical mistake	Using it where continue was meant	Using it where pass was meant	Confused with continue by beginners	Used interchangeably with pass, though semantically distinct

Handling Empty Code Blocks — Python vs Other Languages

This is one of those small syntax differences that genuinely surprises developers coming from brace-based languages, and it's worth seeing side by side.

Feature	Python	Java	JavaScript	C++	C
Block delimiter	Indentation only	Curly braces {}	Curly braces {}	Curly braces {}	Curly braces {}
Empty block syntax	Requires pass keyword	Just {} — nothing needed inside	Just {} — nothing needed inside	Just {} — nothing needed inside	Just {} — nothing needed inside
Error if truly empty	IndentationError	None — valid syntax	None — valid syntax	None — valid syntax	None — valid syntax
Dedicated no-op keyword?	✅ Yes — pass	❌ Not needed	❌ Not needed	❌ Not needed (though ; alone works)	❌ Not needed (though ; alone works)
Philosophy	Explicit is better than implicit	Braces are self-sufficient	Braces are self-sufficient	Braces are self-sufficient	Braces are self-sufficient

Here's my honestly opinionated take: I actually prefer Python's approach here, even though it's objectively one extra keyword to type. An empty {} block in Java or JavaScript can mean three different things depending on context — genuinely intentional no-op, forgotten implementation, or leftover from a refactor — and there's zero textual signal distinguishing them. pass forces a developer to make a deliberate choice and leave a visible marker of that choice. It's more typing for a small amount of extra clarity, and I think that trade is worth it, especially in a language that already prides itself on readability over brevity everywhere else.

Advantages and Limitations of Using pass

pass is about as low-risk a keyword as Python has, but it's not entirely without downsides when used carelessly.

✅ Advantages

Solves a Real Syntax RequirementWithout pass, Python has no other clean way to write a syntactically empty block. It fills an actual grammatical gap, not a stylistic preference.

Zero Performance Overheadpass compiles to one of the cheapest bytecode instructions available. Using it thousands of times in generated stub code has no measurable runtime cost.

Makes Intent ExplicitA block with pass clearly signals 'considered, and deliberately empty' rather than leaving readers to guess whether something was accidentally left out.

Excellent for Rapid PrototypingSketching out entire class hierarchies and function signatures with pass bodies lets you validate structure and imports before writing a line of real logic.

Standard Practice for Stub FilesType-hint .pyi stub files and abstract interface sketches rely on pass as the conventional placeholder — it's the recognised idiom, not a workaround.

Simple, Unambiguous KeywordThere's no configuration, no arguments, no variants. pass means exactly one thing every single time it appears, with no edge cases to memorise.

❌ Disadvantages

Can Mask Forgotten ImplementationA pass left in a function after 'planning' turns into a silent bug the moment that function gets called expecting real behaviour and nothing happens.

Dangerous Inside except Blocksexcept Exception: pass silently swallows errors, hiding real bugs that should surface during development or at least get logged somewhere.

No Warning If Left In ProductionUnlike a linter flag or a TODO comment, a lone pass gives zero automatic signal that something is incomplete — it looks exactly like intentional code because, syntactically, it is.

Easy to Confuse With continueBeginners writing loops sometimes reach for pass when they actually meant to skip to the next iteration with continue, producing logic that silently does the wrong thing.

Not a Substitute for Real Stub SemanticsFor genuine abstract methods that must be overridden, pass alone doesn't enforce that — abc.abstractmethod or raising NotImplementedError communicates that requirement far more strongly.

Where pass Fits — Python Syntax Requirement Architecture

The diagram below shows where the requirement for pass actually originates — it's a direct consequence of how CPython's parser handles indentation-based blocks, not an arbitrary language rule bolted on afterward.

Developer Layer
Source code with if/for/def/classEmpty block intendedpass keyword written
Python Compiler — Lexer
Tokenizes source into INDENT/DEDENT tokensDetects colon (:) as block-start marker
Python Compiler — Parser (AST)
Grammar rule: block requires ≥1 statementpass satisfies this rule as a valid statement node
Bytecode Compiler
pass compiles to NOP-equivalent bytecodeNo operand, no stack effect
CPython Interpreter (PVM)
Executes the no-op instructionFalls through to next statement
Failure Path (Without pass)
Parser finds no statement in blockRaises IndentationError immediatelyProgram never even starts running
Architecture Diagram

pass in Practice — From the Error It Prevents to Real Stub Code

Here's the exact failure first, so the fix actually means something, followed by realistic uses of pass across an if block, a loop, and a class stub.

🐍 Pythonbroken.py

user_logged_in = False

if user_logged_in:

print("Checking dashboard access")

Output

File "broken.py", line 5 print("Checking dashboard access") IndentationError: expected an indented block after 'if' statement on line 3

The fix — and three other realistic uses of pass in the same file:

🐍 Pythonpass_examples.py

user_logged_in = False

# 1. Empty if block — handled deliberately later
if user_logged_in:
    pass  # TODO: redirect to dashboard once auth flow is finalised

# 2. Skeleton class — methods planned, not yet implemented
class PaymentProcessor:
    def charge(self, amount):
        pass

    def refund(self, amount):
        pass

    def validate_card(self, card_number):
        pass

# 3. Loop that only acts on specific items, ignores the rest explicitly
orders = ["pending", "shipped", "pending", "cancelled", "shipped"]
for status in orders:
    if status == "cancelled":
        print("Refund initiated")
    else:
        pass  # pending and shipped orders need no action here

print("Processing complete")

Output

Refund initiated Processing complete

Practice This Code — Live Editor

Line-by-Line Explanation

▶
if user_logged_in: pass — Satisfies the parser's requirement for a statement inside the block, while genuinely doing nothing until the real logic gets written in.
▶
class PaymentProcessor: with three pass-bodied methods — Defines a complete, importable, callable interface. Calling charge() right now runs without error and returns None, which is exactly what an unfinished stub should do.
▶
else: pass inside the loop — Explicitly states that 'pending' and 'shipped' statuses require no action, rather than leaving that branch out entirely and making a reader wonder if it was forgotten.
▶
# TODO: ... next to pass — A comment paired with pass is a common, useful pattern: the comment explains why nothing happens yet, while pass is what actually makes the code valid.
▶
PaymentProcessor().charge(100) would return — None, silently. This is exactly the kind of silent no-op that makes leaving pass in shipped code risky if the caller expects real behaviour.

Where pass Actually Shows Up in Real Codebases

pass isn't just a classroom curiosity — it shows up constantly in real Python code, across several genuinely distinct use cases:

▶
🏗️ API and Interface Prototyping — Before implementing a class's actual logic, developers sketch out method signatures with pass bodies so the rest of the team can start writing calling code, tests, or documentation against a stable interface, entirely in parallel with the implementation work.
▶
📦 Type Stub Files (.pyi) — Static typing tools like mypy rely on .pyi files where function bodies exist purely to declare parameter and return types, with pass as the standard, expected filler for the body — there's no logic to run in a stub file by design.
▶
🧪 Test-Driven Development Scaffolding — Writing test cases before the functions they test even exist is a common TDD pattern. The functions under test often start as pass stubs so imports succeed and the test suite can run — failing meaningfully, rather than crashing on import.
▶
🐛 Custom Exception Class Hierarchies — Defining a custom exception often needs nothing beyond inheriting from Exception: class InsufficientFundsError(Exception): pass. The class needs no extra logic — pass is the entire, correct, complete implementation, not a placeholder.
▶
🔀 Selective Branch Handling in Loops — Data processing pipelines with several elif branches sometimes need most cases to do nothing while a few need real handling — filtering logs, categorising records, routing events — and pass makes the 'do nothing' branches explicit rather than silently absent.
▶
🎓 Teaching Control Flow Structure — Instructors frequently use pass to let students sketch the shape of an if/elif/else chain or loop structure first, confirming the logic flow is correct, before filling in the actual print statements or calculations.
▶
⚠️ Deliberate Error Suppression (Used Carefully) — In cleanup code, resource-closing logic, or non-critical logging paths, except SomeSpecificError: pass occasionally represents a genuinely considered decision that a particular failure mode is safe to ignore — though this should be the exception, not the default habit.
▶
🖥️ Placeholder Command Handlers in CLI Tools — CLI tools with many subcommands sometimes stub out less-used commands with pass during initial development, so the whole command dispatch table exists and can be tested end-to-end before every command has real logic behind it.

Why This Tiny Keyword Actually Matters

It's easy to dismiss pass as too small a topic to spend real time on. Here's why it's worth actually understanding properly rather than just memorising:

▶
🐛 It's the First Syntax Error Many Beginners Hit — Writing an empty if or for block while still planning logic is an extremely natural first instinct, and the resulting IndentationError confuses a lot of new learners who don't yet know pass exists.
▶
💼 It Signals Real Development Habits — Knowing when and where to reach for pass — versus continue, versus raise NotImplementedError — is a small but genuine marker of someone who's actually built things incrementally, not just followed a tutorial start to finish.
▶
🧠 It Reinforces How Python's Grammar Actually Works — Understanding why pass is required teaches something real about how indentation-based parsing works under the hood, which pays off later when debugging trickier indentation-related bugs.
▶
🔒 It Has a Real Danger Mode Worth Knowing — The except: pass anti-pattern is genuinely common in real codebases and genuinely responsible for hard-to-diagnose silent failures. Knowing to be suspicious of it is a practical debugging skill.
▶
🏗️ It's Central to How Professionals Prototype — Sketching interfaces with pass stubs before writing implementation is a real, widely used workflow — not a classroom-only trick — and understanding it properly speeds up how you plan larger pieces of code.
▶
🇮🇳 It's a Standard Early Topic in Indian CS Curricula — Alongside break and continue, pass is typically introduced early in engineering college Python courses and bootcamps aimed at the Indian job market, precisely because it clarifies how Python's block syntax actually works.

pass Across Different Contexts — Where It's Used and Why

pass behaves identically everywhere — it never changes meaning — but the reason for using it shifts depending on which block it sits inside. Here's a breakdown by context:

▶
Inside if / elif / else — Almost always a planning placeholder: 'this condition matters, but the response to it isn't written yet,' or a deliberate 'no action needed for this branch' statement.
▶
Inside for / while loops — Usually marks a branch within the loop body that intentionally requires no processing, distinct from continue, which actively skips remaining code for that iteration.
▶
Inside function definitions (def) — The classic stub function. Signals 'signature exists, implementation pending' — extremely common during interface design and TDD scaffolding.
▶
Inside class definitions — Two distinct sub-cases: an entire empty class body (class Marker: pass, often used for lightweight tagging or namespace objects), or an empty method body inside an otherwise implemented class.
▶
Inside try / except / finally — Most often a deliberate 'this specific failure mode is safe to ignore' decision — though this is exactly the context where pass deserves the most scrutiny during code review.
▶
Inside with blocks — Rare, but occurs when a context manager's side effects (like acquiring a lock or opening a resource) are the entire point, and no additional code needs to run inside the block itself.

Context	Typical Reason for pass	Common Alternative Worth Considering
if/elif/else	Planning placeholder or deliberate no-op branch	None needed if logic is genuinely absent
for/while loop	Explicit 'skip processing, not skip iteration'	continue if you actually want to skip remaining body
def function	Stub during interface design or TDD	raise NotImplementedError for methods that MUST be overridden
class definition	Empty marker class or unfinished method	@abstractmethod (via abc module) for enforced overrides
except block	Deliberate, narrow error suppression	Logging the exception instead of silently swallowing it
with block	Side-effect-only context manager usage	Usually fine as-is — rare and usually correct

Python pass Statement — Interview Questions

These come up often in fresher-level Python interviews, usually as quick fundamentals checks before moving into deeper questions.

pass is a null operation — a statement that does absolutely nothing when executed. Python needs it because the language uses indentation, not braces, to define code blocks, and its grammar requires every indented block to contain at least one statement. Without pass, writing an intentionally empty if, for, def, or class block raises IndentationError, because the parser has no other way to represent 'this block is deliberately empty.'

It silently swallows every exception that occurs in the try block, hiding real bugs, unexpected data, or failures that a developer should actually know about. A program can keep running for a long time, masking a problem, until the accumulated effects of the silently-ignored errors cause a much harder-to-diagnose failure elsewhere. At minimum, exceptions should be logged even if the program chooses to continue past them.

Both can occupy an otherwise-empty block, but they're semantically different: pass is a statement meaning 'do nothing,' while ... (Ellipsis) is an actual object, usable anywhere an expression is valid, not just inside blocks. Ellipsis is more common in type stub (.pyi) files and certain slicing contexts, and some style guides prefer it as a more visually distinct placeholder in stub function bodies. Functionally, for an empty function or class body, both work identically at runtime.

Practice Questions — Test Your Understanding

Work through these before checking the answers. Predicting exact output — and exact error text — is the real test of whether you understand pass or are just recognising the keyword.

1. What does this print? for i in range(3): pass; print(i)

Medium

✅ AnswerThis actually raises a SyntaxError, because you can't put another statement on the same line after pass separated by a semicolon inside a compound statement header like this without proper structure — written correctly across separate indented lines (for i in range(3): pass, followed on the next line by print(i) OUTSIDE the loop, unindented), it prints 2 — the final value i held when the loop finished, since pass does nothing to affect the loop variable.

2. What is the output of: def stub(): pass \n print(stub())

Easy

3. Does class Empty: pass create a usable class, or does it need at least one method to be valid?

Easy

4. In a loop with if status == 'cancelled': refund() else: pass, what would change if you replaced pass with continue instead?

Hard

✅ AnswerIn this specific case, functionally nothing changes, because pass is already the last statement in the loop body — there's nothing after it to skip. continue would jump back to the loop's next iteration, but since the else branch is already the end of the loop body, execution was heading there anyway. The difference would matter only if there were more code after the if/else block within the same loop iteration that continue would then skip but pass would not.

5. What happens if you try to run: pass = 10 as a line of code?

Medium

6. Why might a code reviewer flag a function like def process_refund(amount): pass if it appears in a pull request meant to add real refund logic?

Medium

7. What is the difference in outcome between raise NotImplementedError and pass inside an unfinished method meant to be overridden by subclasses?

Hard

✅ Answerpass silently does nothing and returns None if a subclass forgets to override the method — the bug goes unnoticed until something downstream breaks in a confusing way. raise NotImplementedError immediately and loudly crashes with a clear traceback the moment the un-overridden method is called, making the missing implementation impossible to miss. For methods that genuinely must be overridden, NotImplementedError is the stronger, safer choice.

8. Can pass appear as the only statement in an entire Python file, with no other code at all?

Easy

Conclusion — A Tiny Keyword With a Precise Job

pass is probably the smallest genuine keyword in Python's grammar, and it's tempting to treat it as barely worth a full lesson. But it sits at an honest intersection of two things: a real structural requirement of indentation-based syntax, and a real signal of developer intent — the difference between 'this was forgotten' and 'this was considered and deliberately left empty.' That distinction matters more in a shared codebase than the keyword's tiny footprint suggests.

If you're a complete beginner, the immediate goal is simple: recognise IndentationError: expected an indented block on sight, and know exactly which keyword fixes it. If you're building real, shared code, the deeper goal is knowing when pass is genuinely correct — a marker exception class, a deliberately empty branch — versus when it's secretly hiding an unfinished implementation that needs a louder signal like raise NotImplementedError.

Your Situation	What to Reach For
Genuinely empty block required by syntax	✅ pass
Marker/tag class with no real behaviour	✅ pass — this is the complete, correct implementation
Method that MUST be overridden by subclasses	⚠️ raise NotImplementedError, or @abstractmethod from abc
Want to skip rest of current loop iteration	⚠️ continue, not pass
Want to exit the loop entirely	⚠️ break, not pass
Suppressing an exception you've genuinely evaluated	⚠️ except SpecificError: pass, narrowly, ideally with a log line
Function stub during active development	✅ pass — but track it, don't forget it
Learning Python's block/indentation model	✅ pass is exactly the right place to start

The practical habit worth building here is small but real: every time you type pass, pause for half a second and ask whether it's genuinely the final answer for that block, or a placeholder you need to come back to. Pair it with a TODO comment when it's the latter. That half-second habit is the entire difference between pass as a clean piece of syntax and pass as a bug waiting to be discovered three sprints later.

pass will never do anything, and that's exactly the point. Use it deliberately, track it when it's temporary, and it stays one of the most reliable, low-drama keywords in the entire language. 🐍

Frequently Asked Questions (FAQ)

It can be. except Exception: pass silently swallows every error without any record of it happening, which frequently hides real bugs until they cause much harder-to-diagnose problems later. It's not automatically wrong — there are narrow, deliberate cases where ignoring a specific error is genuinely correct — but as a general habit it's a red flag during code review, and logging the exception is almost always safer than silently discarding it.