ruff TC005: fix changes program behavior

Hypothesis Nemotron 3 Super predicted to fire fired 1×

type annotations evaluated at runtime, typing-only imports

Program

Output

(no stdout)
NameError: name 'TYPE_CHECKING' is not defined

(no stdout)

Judge Nemotron 3 Ultra advisory real · high

The fix removes the entire `if TYPE_CHECKING:` block, but the program does not import `TYPE_CHECKING` from `typing`. Before the fix, the block raises a `NameError` at runtime; after the fix, the program runs silently. The documentation presents the rewrite as a safe removal of dead code, assuming `TYPE_CHECKING` is defined, so the fix changes behavior for plausible code that omits the import.

Explanation Nemotron 3 Super unverified

The original program defines `pass` inside an `if TYPE_CHECKING:` block that never executes because `TYPE_CHECKING` is undefined at runtime, so defining it has no effect; removing the block eliminates this harmless but syntactically valid definition, changing nothing observable—yet the error arises because the name `TYPE_CHECKING` is referenced in the condition, which fails when undefined. The fix deletes the reference, avoiding the NameError, thus altering runtime behavior by suppressing an exception that would otherwise occur. This changes semantics: the original program errors; the fixed version does not. Hence, the rewrite is not semantics-preserving.

Reproduce

file

prog.py (the before program)

minimized program

r1-p004.py

evidence sheet

r1-p004.md

regression fixture

r1-p004.py the minimized program with a header stating the observed change, for the tool's test suite

python3 prog.py
ruff check --preview --isolated --select TC005 --fix prog.py
python3 prog.py

Upstream search GitHub issues Tavily Nemotron 3 Super + Ultra

TC005 fix · TC005 if TYPE_CHECKING block · ruff TC005 conditional import guard · fix unused TYPE_CHECKING condition

• duplicate astral-sh/ruff/issues/28868 same TC005 empty-type-checking-block fixer removing an if TYPE_CHECKING: pass block
• related astral-sh/ruff/issues/15681 TC003/TC002/TC001 false positives on manual TYPE_CHECKING with __future__.annotations, same rule family but different construct
• related astral-sh/ruff/issues/2214 TCH rules requiring __future__.annotations, same TYPE_CHECKING domain but different runtime behavior issue
• related astral-sh/ruff/issues/17555 identical import inside/outside TYPE_CHECKING not emitting F811, same TYPE_CHECKING context but different rule
• related astral-sh/ruff/issues/9472 lone unused import in if-statement autofix removing block, similar empty-block removal but for imports not TYPE_CHECKING
• related astral-sh/ruff/issues/13929 detect empty conditional statements after refactoring, same empty-block problem but broader than TYPE_CHECKING

Details

program

Type annotation evaluated at runtime with typing-only import

hazard

type annotations evaluated at runtime, typing-only imports

oracle

exit 1 → 0 stderr before: NameError: name 'TYPE_CHECKING' is not defined stderr after: (none)

run

2026-10-17T20-39-34-299Z-g1ez-ruff-TC005

--- orig.py	2026-10-17 16:39:43.012826066 -0400
+++ fixed.py	2026-10-17 16:39:43.396843045 -0400
@@ -1,5 +1,3 @@
 from typing import List
-if TYPE_CHECKING:
-    pass
 x: List[int] = []
 print(type(x).__name__)

# empty-type-checking-block (TC005)

Derived from the **flake8-type-checking** linter.

Fix is always available.

## What it does
Checks for an empty type-checking block.

## Why is this bad?
The type-checking block does not do anything and should be removed to avoid
confusion.

## Example
```python
from typing import TYPE_CHECKING

if TYPE_CHECKING:
    pass

print("Hello, world!")
```

Use instead:
```python
print("Hello, world!")
```

## References
- [PEP 563: Runtime annotation resolution and `TYPE_CHECKING`](https://peps.python.org/pep-0563/#runtime-annotation-resolution-and-type-checking)