## 1. What is documented?

The docs makes this even more weird!

> @typing.no_type_check
> Decorator to indicate that annotations are not type hints.
> This works as class or function decorator. With a class, it applies recursively to all methods defined in that class (but not to methods defined in its superclasses or subclasses).
> This mutates the function(s) in place.

https://docs.python.org/3/library/typing.html#typing.no_type_check

Docs do not mention modifing nested classes at all! So, it looks like the `(1)` solution.

## 2. What does it do now?

It modifies nested types, even ones used in assignments.

## 3. How is that used by runtime type inspectors?

I've made a little research:

1. Hypothesis (I help with maintaining its typing API) does not support `@no_type_check` at all: https://github.com/HypothesisWorks/hypothesis/issues/3225

2. Pydantic, looks like `@no_type_check` does not change anything at all.


```
from pydantic import BaseModel
from typing import no_type_check

@no_type_check  # the same with and without this decorator
class MyModel(BaseModel):
    a: int

print(MyModel(a=1))  # ok
print(MyModel(a='1a'))  # ok
# pydantic.error_wrappers.ValidationError: 1 validation error for MyModel
# a: value is not a valid integer (type=type_error.integer)
```

So, it always tries to coerce types. Docs: https://pydantic-docs.helpmanual.io/usage/types/

They also use it inside their own code-base: https://github.com/samuelcolvin/pydantic/search?q=no_type_check Probably for `mypy` to be happy.

3. `dataclasses` and `attrs` - nothing changes. Both do not use neither `@no_type_check` nor `get_type_hints` inside.

Attrs: https://github.com/python-attrs/attrs/search?q=get_type_hints

4. Beartype: https://github.com/beartype/beartype

> We've verified that @beartype reduces to the identity decorator when decorating unannotated callables. That's but the tip of the iceberg, though. @beartype unconditionally reduces to a noop when:
> The decorated callable is itself decorated by the PEP 484-compliant @typing.no_type_check decorator.

So, as far as I understand, they only have `@no_type_check` support for callables. Related test: https://github.com/beartype/beartype/blob/50b213f315ecf97ea6a42674defe474b8f5d7203/beartype_test/a00_unit/a00_util/func/pep/test_utilpep484func.py

So, to conclude, some project might still rely on current behavior that nested types are also implicitly marked as `@no_type_check`, but I cannot find any solid proof for it.

The noticable thing is that this never came up before in ~6 years while this logic exists: https://github.com/python/cpython/blame/8fb36494501aad5b0c1d34311c9743c60bb9926c/Lib/typing.py#L1969-L1970

It helps to prove my point: probably, no one uses it.

## 3. How is that used by runtime type inspectors?
## 4. What would be most useful to runtime type inspectors?

With all the information I gathered, I've changed my opinion :)
Now I think that we should drop the part with modifing nested types at all (`(1)` solution). Only a type with `@no_type_check` should be modified.

This is what docs say. This will also solve the original problem.
Even if someone relies on current behavior: the fix is not hard, just add `@no_type_check` to nested types as well.

So, do others have any objections / comments / feedback? :)