Nikita Sobolev <m...@sobolevn.me> added the comment:
## 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? :) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46571> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
