`mypy` produces errors when run on its own

[tianyizheng02]

Feature description

Apologies if I'm misunderstanding about how mypy is set up with this repo. mypy currently produces a litany of errors when run on its own even though it passes when run as part of pre-commit:

> mypy --ignore-missing-imports --install-types --non-interactive .
dynamic_programming/fibonacci.py:37: note: By default the bodies of untyped functions are not checked, consider using --check-untyped-defs [annotation-unchecked]
dynamic_programming/fibonacci.py:42: note: By default the bodies of untyped functions are not checked, consider using --check-untyped-defs [annotation-unchecked]
searches/binary_tree_traversal.py:21: note: By default the bodies of untyped functions are not checked, consider using --check-untyped-defs [annotation-unchecked]
maths/sigmoid_linear_unit.py:20: error: Function "numpy.core.multiarray.array" is not valid as a type [valid-type]
maths/sigmoid_linear_unit.py:20: note: Perhaps you need "Callable[...]" or a callback protocol?
maths/sigmoid_linear_unit.py:29: error: Unsupported operand type for unary - (np.array?) [operator]
maths/sigmoid_linear_unit.py:32: error: Function "numpy.core.multiarray.array" is not valid as a type [valid-type]
maths/sigmoid_linear_unit.py:32: note: Perhaps you need "Callable[...]" or a callback protocol?
maths/sigmoid_linear_unit.py:51: error: Unsupported left operand type for * (np.array?) [operator]
maths/sigmoid.py:14: error: Function "numpy.core.multiarray.array" is not valid as a type [valid-type]
...
Found 87 errors in 13 files (checked 1143 source files)

Is this expected behavior? Should we expect mypy, when run on its own, to agree with pre-commit?

[Aryank1310]

In general, it's a good idea to run mypy on its own to catch any errors that might not be caught by other tools or in other environments. However, it's also important to make sure that the mypy configuration used when running on its own is consistent with the configuration used in other environments, such as pre-commit.
Although the errors could be because of different configuration,enviornment and timings

[tianyizheng02]

In general, it's a good idea to run mypy on its own to catch any errors that might not be caught by other tools or in other environments. However, it's also important to make sure that the mypy configuration used when running on its own is consistent with the configuration used in other environments, such as pre-commit. Although the errors could be because of different configuration,enviornment and timings

I'm not exactly sure how the pre-commit config differs from the mypy config, if they're indeed different. However, the vast majority of the mypy errors that I'm seeing are about np.array being used as a type. Mypy is definitely correct to mark these as errors because np.array is a function (and np.ndarray should be the correct type), so I don't know why these errors don't appear when mypy is run as part of pre-commit.

[excellentpu]

@tianyizheng02 mypy is a static checking tool used to identify type errors in Python code before it is run. Sometimes, mypy may report errors even though the code is correct. This could be due to the way mypy works.

First, mypy checks type annotations in Python code at runtime and tries to infer the types of variables. It may report errors when it encounters situations where it cannot infer the type of a variable, such as when a variable is not assigned a value.

Second, error reports from mypy may differ due to version and configuration differences. Sometimes, errors may be due to mypy's configuration or compatibility issues with other tools.

If mypy's error reports prevent your code from running, you can try the following solutions:

Update mypy version: Some errors may be due to using an outdated version of mypy. Upgrading to the latest version may resolve the issues.
Check type annotations: Correct usage of type annotations in your code is crucial as mypy works by checking type annotations. If you use complex or custom types in your code, ensure the definitions of these types are correct.
Add more type annotations: Sometimes, mypy errors can be resolved by adding more type annotations. Mypy may generate errors when running alone because it is a static type checking tool that checks type annotations in Python code and reports type errors. If there are type errors in the code, mypy will generate error messages.

[hiranmayee1123]

Here are a few factors that could contribute to the differences you're observing:

Configuration Differences: The mypy configuration used when run on its own might be different from the configuration used by pre-commit. Check if there are any configuration files (e.g., mypy.ini, .mypy.ini, setup.cfg) that pre-commit is using to configure mypy. Ensure that the configuration options and settings are consistent between both invocations.

Environment Variables: mypy can be influenced by environment variables such as MYPYPATH, PYTHONPATH, etc. Make sure that the environment variables are set consistently when running mypy directly and when running it through pre-commit.

File Paths and Context: The way mypy is invoked by pre-commit might affect how it resolves file paths, dependencies, and other contextual information. Ensure that the paths and context are identical or compatible between both invocations.

Version Differences: Make sure that the version of mypy used by pre-commit matches the version you're running on its own. Differences in behavior between mypy versions could also explain the discrepancies.

Plugin Dependencies: If you're using any plugins or additional type stubs with mypy, make sure that they're installed and configured correctly for both invocations.

Command Line Flags: Double-check that the command line flags and options passed to mypy are the same in both cases. Even small differences in flags can lead to different behavior.

[Asukasuk]

Root Cause: Environmental Mismatch
​The pre-commit framework ensures the hook runs reliably by installing mypy and its dependencies into an isolated virtual environment. This isolation is the main culprit for the inconsistent results:
​Missing Type Stubs/Dependencies:
​When running mypy directly, it uses your current virtual environment, which likely has NumPy and the corresponding type stubs (like types-numpy) installed.
​When mypy runs inside the isolated pre-commit environment, that environment does not automatically contain your project's dependencies.
​Analyzing Your Errors: The multitude of errors related to numpy.core.multiarray.array, [valid-type], and "Unsupported operand type" strongly indicates that mypy cannot resolve the types for the NumPy library. It cannot find the type stubs it needs to understand NumPy's functions and operations.
​Configuration and Path Differences:
​Your standalone mypy command uses the configuration file (mypy.ini or pyproject.toml) and command-line arguments you provide (e.g., --ignore-missing-imports, --install-types).
​The pre-commit hook might be configured to use a different set of command-line arguments or might be looking for a configuration file in a different relative path.
Recommended Solutions
​The goal is to make the isolated pre-commit environment aware of the necessary type information.
Configure Additional Dependencies in pre-commit (Recommended)
​You need to explicitly tell the pre-commit hook to install the dependencies and type stubs required to check your code.