`@no_type_check` decorator

No, Annotated does not solve the problem. It attaches extra information to a type, not a variable name. This is a fundamental issue that has come up a few times already. If you want to use annotations only for stuff that isn’t type checking, you would have to write Annotation[Any, ...] everywhere, which is just useless noise. My Proposal would be a massive improvement and would make me agree with you that this Usage is no longer needed. But it would potentially complicate annotation parsers quite a bit.

Which, if you have a really, really weird function (I can’t think of a practical example tbh) would mean adding # type: ignore to every line, which isn’t exactly ideal. But I agree that this is the weakest usecase.

This is incompatible with the basic vision that in python, typing will always be optional. The annotation syntax is quite useful, and stricly reserving it for type checkers is not in the spirit of the original suggestion.

The problem isn’t code bases where you have full control over everything, then you can just not call a static type checker. The worry is about libraries that for example, want to use annotations internally to do something like help with generating C bindings. If those are interfacing with type checked code, the type checker is going to complain about those functions despite nothing being wrong with them.

Sounds like a great linter rule. Completely disallow any and all usage of no_type_check within your code base. I wouldn’t even be opposed to it being a config option for type checkers to raise an error if they see no_type_check. And if you want to not allow pyright to ever allow no_type_check, it just means that I and potentially others who want to use annotations for other stuff are not going to try to support pyright at all.

Either way, the point is that the spec should cover the largest possible usecases. Some of those usecases want to completly disable interpreting annotations as type hints. @no_type_check is the way to currently tell the static type checkers that this is the case.

Note that I am also -1 on completely disabling type checking within such annotated functions. My point is more about the actual annotations. (which would mean a backwards incompatible change in mypy behavior).

2 Likes