# ruff TC005: fix changes program behavior Internal evidence sheet generated by fixhunt. Not an issue text. A human re-verifies, checks the duplicates below, and writes the upstream report in their own words following the project's AI policy. - Tool: ruff ruff 0.17.1 - Rule: TC005 (tool labels the fix: unknown, this fix reported as safe) - Oracle: fix-changes-behavior - Judge (Nemotron 3 Ultra, advisory): real, severity high. The fix replaces the TYPE_CHECKING conditional block with an unconditional 'pass' statement, which changes the function's behavior from raising a NameError (when TYPE_CHECKING is undefined) to silently doing nothing. The documentation presents this rewrite as equivalent removal of dead code, but TYPE_CHECKING is not a built-in constant and the rule does not guard against its absence, making the fix unsafe for code that lacks the typing import. - Program: minimized from 5 to 4 lines ## Reproducer ```python def f(pos, /, kw=None, *args, **kwargs): if TYPE_CHECKING: pass print(f(1, kw=2, extra=3)) ``` ## Commands ```sh python3 prog.py ruff check --preview --isolated --select TC005 --fix prog.py python3 prog.py ``` ## Observed ``` stdout before: stdout after: None exit 1 → 0 stderr before: NameError: name 'TYPE_CHECKING' is not defined stderr after: (none) ``` ## Diff applied by the fix ```diff --- orig.py 2026-10-22 13:30:00.809552958 -0400 +++ fixed.py 2026-10-22 13:30:02.950588778 -0400 @@ -1,4 +1,3 @@ def f(pos, /, kw=None, *args, **kwargs): - if TYPE_CHECKING: - pass + pass print(f(1, kw=2, extra=3)) ``` ## Why the rewrite is not equivalent (model draft, verify before use) The original function contains a conditional block that raises a NameError when executed because `TYPE_CHECKING` is undefined; this error prevents the `print` statement from running. The rewrite removes the condition and replaces it with an unconditional `pass`, allowing execution to proceed to the `print` call, which outputs `None`. Thus, the behavior changes from an error-induced crash to successful execution with output. This alters the program’s observable outcome, so the transformation is not semantics-preserving despite being labeled safe. ## Upstream search Queries: "TC005 fix", "TC005 function parameter slash", "ruff linting conditional block removal", "Oracle behavior type checking guard" - duplicate: https://github.com/astral-sh/ruff/issues/28868 same TC005 empty-type-checking-block fixer removing an if TYPE_CHECKING: pass block and changing behavior - related: https://github.com/astral-sh/ruff/issues/15681 same TYPE_CHECKING concept but false positives on imports with manual TYPE_CHECKING and __future__.annotations - related: https://github.com/astral-sh/ruff/pull/16669 TYPE_CHECKING symbol handling changes affecting type-checking blocks - related: https://github.com/astral-sh/ruff/issues/21921 flake8-type-checking rule about combining imports inside/outside TYPE_CHECKING blocks - related: https://github.com/astral-sh/ruff/issues/14538 TC003 rewrite issues with TYPE_CHECKING blocks causing syntax errors - related: https://github.com/astral-sh/ruff/issues/11103 rule suggestion for enforcing __future__.annotations with TYPE_CHECKING blocks - related: https://github.com/astral-sh/ruff/issues/9573 reharmonizing TCH rules with flake8-type-checking, same rule family
All hits - [github, open] TC004 runtime-import-in-type-checking-block fixer causes follow up: TC005 empty-type-checking-block + F401 unused-import + I001 unsorted-imports — https://github.com/astral-sh/ruff/issues/28868 - [github, closed] unused-function-argument not silenced by prefixed underscore if variable name is "次" — https://github.com/astral-sh/ruff/issues/28721 - [github, closed] Ruff Server errors when using a VSCode interactive session — https://github.com/astral-sh/ruff/issues/11851 - [github, closed] TC003/TC002/TC001 False positive on manual `TYPE_CHECKING` with `__future__.annotations` — https://github.com/astral-sh/ruff/issues/15681 - [github, closed] `TC006` in `0.8.1` is too broad — https://github.com/astral-sh/ruff/issues/14676 - [github, closed] Implement flake8-type-checking — https://github.com/astral-sh/ruff/issues/1785 - [tavily] Can "Unknown rule selector" be a warning, rather than an error? · Issue #5159 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/5159 - [tavily] Consider all `TYPE_CHECKING` symbols for type-checking blocks by MichaReiser · Pull Request #16669 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/pull/16669 - [tavily] new rule - suggest changing function parameter type to readonly alternative if parameter is not mutated inside the function · Issue #24196 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/24196 - [tavily] New rule: fast-api-unused-path-parameter · Issue #12632 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/12632 - [tavily] Allow newlines after block open (or not) · Issue #9745 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/9745 - [tavily] Apply `ruff` formatting to `markdown` code blocks · Issue #3792 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/3792 - [tavily] `flake8-type-checking`: enforce combining imports from inside and outside a `TYPE_CHECKING` block (reverse of `strict`) · Issue #21921 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/21921 - [tavily] TC003’s rewritten annotations have syntax errors and type-checking problems · Issue #14538 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/14538 - [tavily] Rule to enforce usage of `from __future__ import annotations` when imports could be moved to type-checking block ? · Issue #11103 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/11103 - [tavily] Reharmonize `TCH*` rules with flake8-type-checking · Issue #9573 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/9573 - [tavily] F401 false positive when importing in a type-checking block · Issue #12780 · astral-sh/ruff · GitHub — https://github.com/astral-sh/ruff/issues/12780