New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignoring a file with a single # type: ignore comment. #6830
Changes from 5 commits
7a51cf2
aa11089
ce54ab4
4567661
c95b98d
07cc315
9937b1b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -131,6 +131,30 @@ The second line is now fine, since the ignore comment causes the name | |
if we did have a stub available for ``frobnicate`` then mypy would | ||
ignore the ``# type: ignore`` comment and typecheck the stub as usual. | ||
|
||
A ``# type: ignore`` comment at the top of a module (before any statements, | ||
including imports or docstrings) has the effect of ignoring the *entire* module. | ||
|
||
.. code-block:: python | ||
|
||
# type: ignore | ||
import frobnicate | ||
frobnicate.start() | ||
|
||
When running mypy with Python 3.8 or later, a ``# type: ignore`` comment | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This doesn't seem like a very useful behavior to me; when would you actually want this? It's also potentially error-prone. In the example below, a user could write the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For context, pyre's behavior is for an ignore comment on a line by itself to suppress errors on only the next line: https://pyre-check.org/docs/error-suppression.html#explicitly-suppressing-errors. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Why would you expect that to work? Also, the behavior implemented here is specified by PEP 484. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had assumed that there was some degree of consensus between discussion on #626 and the relevant section of PEP 484 that a One scenario I can imagine is somebody working their way through an existing code base with several large modules, adding or correcting annotations as they go. Test code also comes to mind, where you may have several fixtures you want type-checked near the top of the module, but intentionally broken code after that. If we decide that the ignore-rest-of-file-on-3.8 part of this PR should be removed or deferred, I'm fine with that, though. I added it because I could for 3.8, but I'm certainly not married to it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It's the intuitively more obvious behavior to me (which, granted, is not a very strong argument), and it's also what Pyre implemented. On the other hand, pytype's behavior is closer to what PEP 484 specifies, but with a way to turn type checking back on: https://github.com/google/pytype/blob/master/docs/user_guide.md#silencing-errors.
That's true, but this is a part of PEP 484 that has remained unimplemented in mypy for five years. As far as I can tell there have been few if any user requests for the full behavior specified in PEP 484鈥攗sers want to be able to ignore the whole file, but I don't see people asking for "ignore errors from an arbitrary point to the end of the file". So I think it's worth asking if the PEP 484 behavior really is what we want. We can always change PEP 484 too. If #2938 is implemented, even using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, I'm happy to take this to the python/typing tracker to discuss potentially changing the PEP. My concern on this PR is that we don't introduce this behavior into mypy too soon and produce backward compatibility problems if we ever decide to change it. |
||
anywhere at the top indentation level of a module will skip type checking for | ||
all remaining lines in the file. | ||
|
||
.. code-block:: python | ||
|
||
"""Docstring.""" | ||
|
||
import spam # These imports are still checked! | ||
import eggs | ||
|
||
# type: ignore | ||
import frobnicate | ||
frobnicate.start() | ||
|
||
Another option is to explicitly annotate values with type ``Any`` -- | ||
mypy will let you perform arbitrary operations on ``Any`` | ||
values. Sometimes there is no more precise type you can use for a | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This hardly qualifies as "locally" silencing the checker, so I think it doesn't belong in this section.
I would make it a new section titled "Ignoring a whole file" to be inserted after this section (i.e. just before the section named "Unexpected errors about 'None' and/or 'Optional' types").
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've broken it out, as requested.