Add option to selectively disable --disallow-untyped-calls #15845

ilevkivskyi · 2023-08-10T20:53:10Z

It is surprisingly one of the most upvoted issues. Also it looks quite easy to implement, so why not. Note I also try to improve docs for per-module logic for disallow_untyped_calls, as there is currently some confusion.

JukkaL

Thanks, this seems useful! Not a full review.

JukkaL · 2023-08-11T15:41:35Z

docs/source/command_line.rst

+
+    .. code-block:: python
+
+        # mypy --disallow-untyped-calls  --untyped-call-exception=foo --untyped-call-exception=bar.A


Maybe also use a real third-party package in the example, such as numpy?

JukkaL · 2023-08-11T15:43:50Z

mypy/checkexpr.py

+                assert object_type is not None
+                fullname = self.method_fullname(object_type, member)
+            if not fullname or not any(
+                fullname.startswith(p) for p in self.chk.options.untyped_call_exception


Make sure the exception re doesn't apply to retry, i.e. the startswith operation should probably be at module name component level.

Good catch!

JukkaL · 2023-08-11T15:45:26Z

docs/source/config_file.rst

+        disallow_untyped_calls = True
+        untyped_call_exception = some.library
+
+.. confval:: untyped_call_exception


This seems useful, but I'm not sure about the name of the option. Maybe we can come up with a better name? I don't any suggestions right now, but I'll think about this later.

I also struggled some time with this. I would propose to not spend much time on this. People who want this will probably search for "mypy untyped call" or similar, so including these words in the option name should be good enough. So if you have a better idea, then I will be happy to update, otherwise let's just move on.

Fwiw I'd go with untyped_call_allowlist. Clearly conveys the type as well ;-)

This is what I considered at first, but then how wold we call corresponding command line option? --untyped-call-allowlist? All other options like --always-true, --always-false, --enable-error-code, --disable-error-code etc, are singular and should be repeated. So I would say we should try to follow this pattern. Finally, from reading comments in the issue, it looks like most people will need just 1 or maybe 2 exceptions, not more.

JukkaL · 2023-08-11T15:45:54Z

docs/source/config_file.rst

+    :type: comma-separated list of strings
+
+    Selectively excludes functions and methods defined in specific packages,
+    modules, and classes from action of :confval:`disallow_untyped_calls`.


Mention that this also applies to submodules of packages (i.e. everything inside that prefix).

AlexWaygood · 2023-08-11T17:55:31Z

docs/source/command_line.rst

+    This flag allows to selectively disable :option:`--disallow-untyped-calls`
+    for functions and methods defined in specific packages, modules, or classes.
+    Note that each exception entry acts as a prefix. For example (assuming there
+    are no type annotations for ``numpy`` available):


Numpy's probably not a great example here, as they ship with a py.typed file these days and have pretty complete type annotations. Maybe one of matplotlib, requests or TensorFlow might be a better example? Third-party stubs exist for all three packages, but none of them ships with a py.typed file

Any example of a popular library might become a bad example over time, maybe limit ourselves to something generic like third_party_lib?

Yeah, let's use some generic name.

ilevkivskyi · 2023-08-12T21:20:25Z

IIUC the only remaining question now is the name of the new flag. I propose that instead of keeping this open indefinitely, merge this as is, and then think about it until the next release. It will be easy to rename it if a better idea appears. If there are no objections, I am going to merge this tomorrow or Monday.

hauntsaninja

Thanks, this is a nice feature. Agreed we can merge. How do you feel about just --untyped-call-allow? I like using "allow" because it's a verb we use in a lot of places and because exception makes me think of the language feature

ilevkivskyi · 2023-08-13T09:49:15Z

Yes, -exception can make one think this is something about exceptions. But also then --untyped-call-allow would be too similar to --allow-untyped-calls (which is also a valid flag). I think it may be better to use --untyped-calls-exclude because:

It is also a verb an indeed we mostly use verbs for many flags (especially for strictness flags)
It doesn't have the exception connotation
It is sufficiently different from --exclude flag (and they are kind of similar btw, exclude also expects list of patterns)
It still seems to clearly indicate what it does: exclude certain functions from untyped calls check.

github-actions · 2023-08-13T10:52:17Z

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

hauntsaninja · 2023-08-13T17:44:50Z

Great, I like it!

WilliamKozickiGF · 2023-10-26T05:45:33Z

Hey, I just want to say, god bless you guys for adding this feature. I started using mypy last week and have thought that there has to be a way to do what untyped_calls_exclude does. It's hard to believe that this was only added this recently.

johnthagen · 2023-10-30T12:36:33Z

For those looking for a pyproject.toml config example for this:

[tool.mypy]
strict = true
untyped_calls_exclude = [
    "skimage"
]

This ignores all errors from missing type annotations in the skimage third party package when imported and used in user code.

Add option to selectively disable --disallow-untyped-calls

47f2487

ilevkivskyi requested review from JelleZijlstra, JukkaL and hauntsaninja August 10, 2023 20:53

This comment has been minimized.

Sign in to view

ilevkivskyi force-pushed the untyped-allowlist branch from 3eea8d1 to 47f2487 Compare August 10, 2023 22:33

This comment has been minimized.

Sign in to view

JukkaL reviewed Aug 11, 2023

View reviewed changes

Address CR

8055516

AlexWaygood reviewed Aug 11, 2023

View reviewed changes

This comment has been minimized.

Sign in to view

Fix module names

6e20a87

This comment has been minimized.

Sign in to view

hauntsaninja approved these changes Aug 12, 2023

View reviewed changes

Try different name for the flag

83df5dd

ilevkivskyi merged commit 117b914 into python:master Aug 13, 2023
19 checks passed

ilevkivskyi deleted the untyped-allowlist branch August 13, 2023 20:20

ilevkivskyi mentioned this pull request Aug 13, 2023

Ignore typing errors in individual blocks #6948

Open

tlambert03 mentioned this pull request Oct 5, 2023

Include py.typed file in distribution (PEP 561) scikit-image/scikit-image#7073

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add option to selectively disable --disallow-untyped-calls #15845

Add option to selectively disable --disallow-untyped-calls #15845

ilevkivskyi commented Aug 10, 2023

This comment has been minimized.

This comment has been minimized.

JukkaL left a comment

JukkaL Aug 11, 2023

JukkaL Aug 11, 2023

ilevkivskyi Aug 11, 2023

JukkaL Aug 11, 2023

ilevkivskyi Aug 11, 2023

hauntsaninja Aug 11, 2023

ilevkivskyi Aug 11, 2023 •

edited

JukkaL Aug 11, 2023

AlexWaygood Aug 11, 2023

ikonst Aug 11, 2023

ilevkivskyi Aug 11, 2023

This comment has been minimized.

This comment has been minimized.

ilevkivskyi commented Aug 12, 2023

hauntsaninja left a comment

ilevkivskyi commented Aug 13, 2023

github-actions bot commented Aug 13, 2023

hauntsaninja commented Aug 13, 2023

WilliamKozickiGF commented Oct 26, 2023

johnthagen commented Oct 30, 2023 •

edited


		.. code-block:: python

		# mypy --disallow-untyped-calls --untyped-call-exception=foo --untyped-call-exception=bar.A

Add option to selectively disable --disallow-untyped-calls #15845

Add option to selectively disable --disallow-untyped-calls #15845

Conversation

ilevkivskyi commented Aug 10, 2023

This comment has been minimized.

This comment has been minimized.

JukkaL left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ilevkivskyi Aug 11, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

ilevkivskyi commented Aug 12, 2023

hauntsaninja left a comment

Choose a reason for hiding this comment

ilevkivskyi commented Aug 13, 2023

github-actions bot commented Aug 13, 2023

hauntsaninja commented Aug 13, 2023

WilliamKozickiGF commented Oct 26, 2023

johnthagen commented Oct 30, 2023 • edited

ilevkivskyi Aug 11, 2023 •

edited

johnthagen commented Oct 30, 2023 •

edited