disallow_untyped_calls in module does not override global section

Bug Report
Since updating numpy from version "1.20.3" to version "1.21.0" we are getting the following errors:

error: Call to untyped function "load" in typed context

We want to suppress errors about untyped calls from numpy - but not globally.

To Reproduce

(Write your steps here:)

files mypy.ini:

[mypy]
disallow_untyped_calls = True
[mypy-numpy.*]
disallow_untyped_calls = False

example.py:

import numpy as np


def fun() -> None:
    np.save("path", [1, 2])

Call with: mypy example.py --config-file mypy.ini

Expected Behavior

Expected to not see an error about: Call to untyped function

Actual Behavior

Actual: example.py:5: error: Call to untyped function "save" in typed context

Your Environment

Mypy version used: mypy 0.812
Mypy command-line flags: --config-file mypy.ini
Mypy configuration options from mypy.ini (and other config files):
Python version used: Python 3.8.10
Operating system and version: Ubuntu 20.04.2 LTS
Numpy version: 1.21.0

Note: setting disallow_untyped_calls to False globally does work (but is undesired)

I am affected by the same problem, using these versions:
Python 3.9.5

mypy==0.910
mypy-extensions==0.4.3
numpy==1.21.1
pkg_resources==0.0.0
toml==0.10.2
typing-extensions==3.10.0.0

I am affected by the same problem. Any progress on this?

As an additional data point: I have the same problem (with selenium).

Same on my side, I have the issue with zeep

Same for me, I have the issue with dask.distributed.

Could anyone clarify why is this labelled as a "bug"? It may be a feature request, but certainly not a bug. You disable error code for module, where it is located. The posted error is not located in numpy module - it resides in your own module, example. You cannot currently say "disable errors called on numpy objects" - this is a difficult to implement and rarely useful feature. You can only disable error for some line, for a file (inline ignore) or for a file or whole module with config file entry.

@icepython

Let me start with apologising if any of the following sounds rude or is too verbose - my intention was to point out exactly why I would label this as a bug. It not my intention to criticise the project and am sorry if you think I unfairly did so.

Could anyone clarify why is this labelled as a "bug"?

(I assume) it is labeled as bug because it is counter-intuitive given how the rest of the configuration works and how the documentation explains that the configuration can be used (the docs suggest that any and all things can be overriden like the example provided by @icepython in the the initial report.

As a user of mypy - and someone typically willing to recommend using it - I'd prefer if the mypy team

either, preferred allow users to override these kind of settings like this because some third party modules have types and some don't.
or make amends to specific sections of documentation to point out that these cannot be overwritten.

If I may provide another sample, from configuration I work with:

[tool.mypy]  # https://mypy.readthedocs.io/en/stable/
show_error_codes = true
show_column_numbers = true
[...]

[[tool.mypy.overrides]]
module = [
  "docker.*",
  "etcd3gw.client"
]
ignore_missing_imports = true

Using this snippet and it's wording with overrides, it makes one believe even stronger that the mentioned feature - configuring specific things for specific 3rd party libraries - is indeed possible.

Here's the specific section from the documentation that made me initially believe this is possible:

[mypy-mycode.foo.*]
disallow_untyped_defs = True

There's also the following

Some of the config options may be set either globally (in the [mypy] section) or on a per-module basis (in sections like [mypy-foo.bar]).
If you set an option both globally and for a specific module, the module configuration options take precedence. This lets you set global defaults and override them on a module-by-module basis. If multiple pattern sections match a module, the options from the most specific section are used where they disagree.
Some other options, as specified in their description, may only be set in the global section ([mypy]).

After reading it, I scroll to the section "Untyped definitions and calls", subsection "disallow_untyped_calls", read the content. No mention it's global. I read the section text itself, no mention either; therefor, I assume it is intended to work like the people in this thread want.

Source: https://mypy.readthedocs.io/en/stable/config_file.html

You cannot currently say "disable errors called on numpy objects" - this is a difficult to implement and rarely useful feature.

this would be a ubiquitously useful feature, as it would allow projects to maintain fully strict typing while excepting calls made out to third party libraries that are not fully typed. As it is now, any third party library on pypi that isn't fully typed itself is unusable with an application that wishes to maintain strict typing for its own calls.

I agree that the "disallow_untyped_calls" refers to calls made in the target source file, however this use should be clarified in the documentation, as you can see a lot of people hit this and are confused by it. Also, the fact that mypy currently has no way for full "strict" use while using third party libraries that have functions untyped should be noted.

Just started using mypy and ran into this issue in <48 hours. As other have said, some libraries have types and some don't so this is really obviously a bug.

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

Navigation Menu

Repository navigation

disallow_untyped_calls in module does not override global section #10757

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

disallow_untyped_calls in module does not override global section #10757

Description

Activity

skogler commented on Aug 2, 2021

hasansalimkanmaz commented on Apr 4, 2022

ZeeD commented on Jun 4, 2022

martinlehoux commented on Dec 8, 2022

nsthorat commented on Apr 10, 2023

sterliakov commented on Apr 11, 2023

GhostLyrics commented on Apr 11, 2023

zzzeek commented on May 10, 2023

samskiter commented on May 15, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions