This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sobolevn
Recipients AlexWaygood, JelleZijlstra, gvanrossum, kj, sobolevn
Date 2022-01-30.07:31:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
## 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.

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:

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:

They also use it inside their own code-base: 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.


4. 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:

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:

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? :)
Date User Action Args
2022-01-30 07:31:26sobolevnsetrecipients: + sobolevn, gvanrossum, JelleZijlstra, kj, AlexWaygood
2022-01-30 07:31:26sobolevnsetmessageid: <>
2022-01-30 07:31:26sobolevnlinkissue46571 messages
2022-01-30 07:31:26sobolevncreate