TC006 (runtime-cast-value) shouldn't trigger with `annotations`

[Kilo59]

Summary

TC006 forces the use of quotes strings around casts types even when from __future__ import annotations is imported.

The explanation of the rule doesn't apply when using a postponed annotations.
https://docs.astral.sh/ruff/rules/runtime-cast-value/

# runtime-cast-value (TC006)

...

It's often necessary to quote the first argument passed to `cast()`,
as type expressions can involve forward references, or references
to symbols which are only imported in `typing.TYPE_CHECKING` blocks.
This can lead to a visual inconsistency across different `cast()` calls,
where some type expressions are quoted but others are not. By enabling
this rule, you ensure that all type expressions passed to `cast()` are
quoted, enforcing stylistic consistency across all of your `cast()` calls.

In some cases where `cast()` is used in a hot loop, this rule may also
help avoid overhead from repeatedly evaluating complex type expressions at
runtime.

Important

In addition, by forcing the use of quoted strings instead of postponed annotations we >introduce a very subtle but potentially serious type-checking footgun.

That is if the TYPE_CHECKING import ever changes, the quoted string reference will silently become an Any, and neither ruff nor mypy will be able to catch it.

Full example of this issue described here 👇

• autofix for TCH (flake8-type-checking) rules #2329 (comment)

Note: There may be some configurations of mypy that will catch this (if Any is banned outright for example), but most configurations likely won't catch it.

[ntBre]

I might be missing something, but it looks like the arguments to cast are still evaluated at runtime, even with from __future__ import annotations:

>>> import typing
>>> if typing.TYPE_CHECKING:
...     from collections import Counter
...
>>> typing.cast(Counter, 123)
Traceback (most recent call last):
  File "<python-input-2>", line 1, in <module>
    typing.cast(Counter, 123)
                ^^^^^^^
NameError: name 'Counter' is not defined
>>> from __future__ import annotations
>>> typing.cast(Counter, 123)
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    typing.cast(Counter, 123)
                ^^^^^^^
NameError: name 'Counter' is not defined
>>> from collections import Counter
>>> typing.cast(Counter, 123)
123

so I don't think the quotes should be suppressed, as would be the case in other annotation contexts.

[Kilo59]

@ntBre Thanks for the quick response.
Your example doesn't match the scenario I'm describing.
It should be..

>>> from __future__ import annotations
>>> import typing
>>> if typing.TYPE_CHECKING:
...     from collections import Counter
...
>>> typing.cast(Counter, 123)
123

[ntBre]

Did you try running that code? I'm still getting an error in a fresh Python REPL:

Python 3.13.5 (main, Jun 21 2025, 09:35:00) [GCC 15.1.1 20250425] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import annotations
>>> import typing
>>> if typing.TYPE_CHECKING:
...     from collections import Counter
...
>>> typing.cast(Counter, 123)
Traceback (most recent call last):
  File "<python-input-3>", line 1, in <module>
    typing.cast(Counter, 123)
                ^^^^^^^
NameError: name 'Counter' is not defined

and also when running this script:

from __future__ import annotations
import typing

if typing.TYPE_CHECKING:
    from collections import Counter

typing.cast(Counter, 123)

> python try.py
Traceback (most recent call last):
  File "/tmp/tmp.4i5jouRHcG/try.py", line 7, in <module>
    typing.cast(Counter, 123)
                ^^^^^^^
NameError: name 'Counter' is not defined

[Kilo59]

@ntBre You're right. That example does error for me as well 🤔.

I'm a bit confused tho, I have other examples of currently running code that don't error in the same scenario.
Intuitively it doesn't make sense to me; a postponed annotated Counter should be the same as "Counter" at runtime.

Let me try to come up with an MRE that doesn't error.

[Kilo59]

Okay here's a working example that still triggers the ruff rule and doesn't crash at runtime.

❯ python --version 
Python 3.13.5

from __future__ import annotations

from typing import Literal, cast, TypeAlias

type MyType = Literal["foo", "bar"]

# alternate type
# MyType: TypeAlias = Literal["foo", "bar"]


def foo(value: str) -> MyType:
    return cast(MyType, value)


print(foo("trust me"))

This works of course because the type is defined at runtime.

Whatever the case, sounds like any exception to the rule can't be as simple as checking for a from __future__ import annotations import 😔 . The rule is still unnecessary in this limited scenario, but probably not worth creating the special case inside ruff.

My issue is really with cast then, I don't understand why it needs to do anything at runtime?? 🤷
I basically only use cast inside of test code, so I'm going to just disable the rule (for my tests dir).

@ntBre thanks again.

[ntBre]

No problem, I was confused too! The cast docs even say:

This returns the value unchanged. To the type checker this signals that the return value has the designated type, but at runtime we intentionally don’t check anything (we want this to be as fast as possible).

emphasis mine. But I think the arguments to cast still have to be evaluated, which is separate from cast doing anything with them internally.