You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree that this is indeed problematic. For example:
x=1reveal_type(x)
Mypy checks this code, finds 0 issues, returns 0 as the return code. This script will pass the CI, but will break in runtime. This is not what mypy is expected to do: it is expected to find bugs.
So, I propose adding a new error code:
We can name it unimported-reveal
It will be turned off by default
It will raise errors on all plain reveal_type / reveal_locals usages
If you want to keep reveal_type even in production (for some reason), use from typing[_extensions] import reveal_type or type: ignore[unimported-reveal]
Do others have any objections?
The text was updated successfully, but these errors were encountered:
Note: `reveal_type(1) # type: ignore` is problematic, because it
silences the output. So, I've added some docs to advertise not doing so.
Closes#16270
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Some of our users report that
reveal_type
causes problems in runtime: typeddjango/django-stubs#590I agree that this is indeed problematic. For example:
Mypy checks this code, finds 0 issues, returns 0 as the return code. This script will pass the CI, but will break in runtime. This is not what mypy is expected to do: it is expected to find bugs.
So, I propose adding a new error code:
unimported-reveal
reveal_type
/reveal_locals
usagesreveal_type
even in production (for some reason), usefrom typing[_extensions] import reveal_type
ortype: ignore[unimported-reveal]
Do others have any objections?
The text was updated successfully, but these errors were encountered: